On Thu, Oct 21, 2010 at 6:03 AM, Burcin Erocal <bur...@erocal.org> wrote: > On Sun, 17 Oct 2010 15:56:41 +0100 > Martin Albrecht <martinralbre...@googlemail.com> wrote: > >> > I was thinking of setting up trac to send a notice to a mailing list >> > for each new issue. Then people interested in this effort can follow >> > this list and help out. Is this possible? Can someone familiar with >> > the trac set up comment? >> >> > IMHO, distributing work day by day, or weekly is still putting too >> > much load on one person. It should be enough if someone contributes >> > to one issue per day. >> >> > Perhaps we should come up with a locking mechanism, to prevent two >> > different people from trying to sort the same issue at the same >> > time, but it feels like too much organization at the beginning. >> >> My guess would be that we won't have the issue with locking very >> often (i.e. too many people doing too much work) but with no one >> feeling responsible. I guess for me your suggestion would turn out >> something like this: >> >> 1) I sign up to that mailing list since I feel a responsibility of >> contributing to Sage in such a way >> >> 2) For the first few days or weeks I go through newly opened tickets >> as you suggested. >> >> 3) Eventually, probably in some phase where I have less disposable >> time, I give up on dealing with this e-mail since "somebody else will >> take care of it". > > I know this scenario too well. We should try to avoid overloading > people or relying on the efforts of only a few people as much as > possible. > >> Of course, the answer could just be to not do step 3, but I would >> assume that it would happen to many of us. Being responsible for a >> week a time is something more local or short-time which would make it >> easier for me to commit. > > The week at a time approach you describe below is too much work for me. > I doubt if I could put in 2 hours of work for Sage everyday for a whole > week. I do however look at the new tickets on trac from time to time, > and wouldn't mind either classifying a few of the new ones properly, or > reading emails to see if a new developer has done it properly. > >> To given an example of the workload here's the list of tickets >> created on the 15th. It seems 3-5 new tickets a day is the normal >> load: >> > <snip ticket descriptions> >> Thus, as a rule of thumb we could say whoever is responsible for a >> day should deal with five tickets old and new. This seems like about >> 1-2h of work which seems doable to me. >> >> Of course, if many people feel differently then we should choose a >> different path. > > I suggest still setting up a mailing and assigning all new bugs to a > B-team user on trac with email address pointing to this list. > > Following your suggestion, to make sure there is someone "in charge" for > a particular day, we can set up a wiki page to sign up for days (not > weeks). It would be great if we can have at least 2 people on call for > a day. Though it is not a disaster if a few new entries get missed, > since we can always process them later. We just need to make sure not > to build a huge backlog, and do as much preprocessing as possible before > assigning a bug to a developer. > > For anyone who cannot commit to a regular schedule, a search on trac for > tickets assigned to the B-team will point what needs to be classified, > so they can help at any point without signing up if they wish to. > > The B-team should be responsible for doing the following before passing > a bug on to a developer: > > - make sure there is enough information to reproduce the problem > > - check if it is already reported, if so close the current as a > duplicate > > - find which area of the code the problem seems to occur > > People can always ask for help on the mailing list if there is a > problem with this phase. > > - assign to a developer only if they agree to work on the problem, > otherwise leave the issue in a "confirmed" state, assigned to > "tbd" (these terms can also be used to search for things to do...) > > The B-team can also handle the "report a problem" link from the > notebook, the problems reported on ask.sagemath.org, or the > sage-support mailing list, as required. > > > Comments? > > Any takers? I'd like it if someone takes the lead for the next few > months, since I really need to be working on finishing my thesis. I am > still willing to spend some time on bug wrangling these days, since I > try to do that already (like quite a few other people) so I can still > sign up for some days.
I'd certainly be willing to pitch in, but probably wouldn't be able to commit to specific days. If no one's opposed, I'll at least add a "confirmed" state on trac. - Robert -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
