Steve Youngs writes:
[snip]
> o Constant communication between the bug submitter and Us. With as
> much as possible being automated so it isn't forgotten about.
This shouldn't be *too* automated though, the best way, I think is to
have a mailing list subset for each bug*, the submitter can choose to
subscribe to. This should be as easy as replaying to the ack mail.
Then the submitter can get all traffic regarding that bug, be it
developer discussion, closed becouse of duplication (in which case,
the submitter should be subscribed to the previous bug), and finally
notified when it's closed becouse of being fixed ;)
* I have no idea how to implement this though ;/
Replying to the ack mail also rids us of trying to contact invalid
addresses and so on and so forth.
But even if the ack mail is not responded to (simply becouse the
submitter is already flooded with mail and is afraid of more or
something) it should *not* be forgotten about.
> o A real live person to get into contact with the bug submitter
> _within 48 hours_ of the bug report coming in.
Emm, it's not like I'm against this, but could we have a scenario?
> o In absolutely no circumstances will any bug report get lost or
> forgotten or neglected. I want the bug tracker to send out
> automated reminders to whoever takes responsibility for the bug.
> The higher the priority of the bug, the more frequent the
> reminders.
Or in the case there is no one responsible, it should be sent to the
one responsible for assigning the bugs ;)
> Feature requests and support requests should work the same way as bug
> reports. Although I believe that support requests should generate
> contact from a real live person _within 24 hours_.
Hmm, k, I think I'm pretty cool with that.
> Patch tracking will probably work in a similar way too. I'd
> definitely want `M-x sxemacs-submit-patch' to automate the process for
> the user.
Or M-x sexually-submit-patch ?
> For us with patches, I'm not going to put too many restrictions on
> it. Basically once you have commit privileges you'll be able to
> commit when or what you like (there may be times when this isn't the
> case). If you fuck something up you immediately remove it or fix it.
> Simple.
For the development branch, yes, but what about stuff we have claimed
as stable? Then there should be manual scutiny of the patches, no?
> Obviously it goes without saying that you'd inform us of your plans
> here before you start committing oodles of new whiz-bang features.
As will be stated in the PPM, right?
> CVS can easily be made to post diffs to a "sxemacs-patches" mailing
> list.
But are we so hell bent on CVS?
> Well that's pretty much how I see SXEmacs Issue Tracking. I've only
> heard of three issue trackers... BugZilla, Gnats, and whatever SF and
> Savannah uses. I don't know any of them all that well.
And I know none of them at all..
> Give me options folks! Is there anything out there that will give us
> what I want?
The only thing I can think of is M-x extrapolate
Have fun,
Johann
|