package shepherding

[Mark McLoughlin]

Hi Jef,

On Wed, 2004-03-03 at 19:57, Jef Spaleta wrote:
> Mark McLoughlin wrote:
> > Yeah, I can appreciate that - I'm still figuring it out too. It 
> > would be good though if we could have a general 
> > "bugzilla.redhat.com policy" doc or something. Would you have the >
> time to start compiling that?
> 
> No, I don't have time, but its near the top of the list of things i
> don't have time for. I'm desperately in search for a sucker..err
> volunteer that is interested in producing documentation, so I don't
> have to keep pretending like i know what I'm doing.  And I think,
> considering how things are actually developing, it probably a stretch to
> call any document of this sort that i might write "policy" in the sense
> that developers are actually going to be encouraged by leadership to
> follow what's written.    At best its more like "Jef's bugzilla for
> dummies" or "Jef's fireside bugzilla ghost stories" as a companion piece
> to "Jef's 12 easy steps to applying cat herding techniques to open
> source developer management"

	I would expect that any doc like this would be initially written up by
some person, posted to this list, argued over by package maintainers,
developers and shepherders alike and over time massaged into something
everybody pretty much agrees on. I think you could easily christen
something like that as a "policy" :-)
 
> > e.g. we were discussing today on irc whether its valid to mark a 
> > RHEL bug as a dup of a Fedora bug. The conclusion we came to was:
> 
> You are going to hate me, as much as I like see exactly this sort of
> discussion, and I'm more than happy to take the fruits of discussion
> that I'm not actively involved with(I'm an invented anywhere but by me
> sort of person)...its very difficult to actually keep track with nuggets
> of information like this if I have to pick them up from the
> fedora-devel-list. 

	That's why even a rough set of notes keeping track of stuff like this
would be helpful for when someone does have the time to try and codify
it properly.

> > <markmc> if its sufficient to be fixed in a future release
> > <markmc> mark it as a dup
> > <markmc> if it needs to be fixed now, then leave it open
> > <markmc> and include a link to the dup
> 
> These are the sort of judgement calls that are difficult to codify.
> And really require active discussion between package maintainer and the
> triagers who want to help with a specific package. Don't really want to
> encourage a situation where a triager is deciding what should and should
> not be fixed now without feedback from the maintainer, and conversely
> don't want to encourage a situation where a triager is demanding a
> significant amount of time from developers
> to get feedback about whether or not a collection of bugs are close now
> or keep open.  As guidance for developers and package maintainers this
> makes sense. As guidance for triagers looking to help maintainers, this
> is probably not something i want to start with.

	Agreed. Totally. What I'm trying to get it is the "policy" is probably
nearly as undefined and confusing for developers as it is for triagers.
So any "policy" doc would help everyone. And FWIW, what you just said
would itself be very useful in such a doc.

Cheers,
Mark.