I'm +1 for the 3 months proposed by Xavier. I'd even say 2 instead, but one month does not really make a difference. I agree 1 month can be too short.
I'm +1 for the rest of Michelle's proposals. I also like Xavier's idea of classifying the developers by areas of expertise. Regards Rubén Pérez TELTEK Video Research www.teltek.es 2012/9/12 Xavier Butty <[email protected]> > Hi, > > > 3 (Proposal). Continuing from point 2, committers who have not > > contributed in more than a month will retire to committers emeritus. > > Hopefully this will prompt our institutional leads to commit to public > > Matterhorn development. > -1: I also think that one month is too short. If people are in holidays or > other (like the 3 annual weeks of military services for us in Switzerland), > a month is quickly over. > But 6 month is too long as well. If you are not able to > commit/contribute something during 6 month, it definitely means that you > are not active. Therefore --> committers emeritus. > 3 month would be a good compromise. > > > 4 (Proposal). We keep a list of committers and their organizations on > > the front project (or wiki, whichever's easiest) page. This will > > highlight those who are contributing. > +1: Should we also list the committers per fields of competence. It could > help to assign/contact someone to work on tickets and assign the related > people for the code reviews. > > Xavier > > On Sep 11, 2012, at 6:24 PM, Greg Logan <[email protected]> wrote: > > > Hi folks, > > > > Sorry for the crosspost, but I wanted to make sure I hit everyone. As > > we sat at the dev meeting today, we realized that our normal ticket > > review would be silly because no tickets had been resolved in the last > > week. After much discussion, we came to a few conclusions: > > > > A. We have little to no visibility of actual developer availability. > > We don't know how much time in a given week that a developer has to work > > on public Matterhorn related tickets. > > > > B. The attendance in the developer meeting has been going steadily down > > hill. In theory, if you have commit privileges you are expected to > > attend these meetings. This hasn't been happening. > > > > C. Tasks which are assigned frequently don't get finished (see point > > A), but tasks which are unassigned are extremely unlikely to ever be > > addressed given that very few developers are looking through the > > unassigned task list. > > > > To address these issues, we propose that the project will try the > following: > > > > 1. We ask that the committers and developers let us know how much time > > they have tasked to public Matterhorn tasks. I'm going to be working > > with the board to try and get these numbers nailed down. There's no > > shame in not having any time to work on Matterhorn, but if you don't > > have time then your tickets won't get done, which leads to point 2. > > > > 2. Developers should go through their tickets, and unassign those which > > they do not have the time to work on. If you're currently working on it > > mark it as in progress and post a comment explaining where you are, and > > if you're going to do it but haven't had a chance yet then put a comment > > on the ticket explaining what's blocking your progress. Concentrate on > > the 1.4 tickets for now. In one week I will be going through and > > unassigning tickets which have not been updated in a week. > > > > 3 (Proposal). Continuing from point 2, committers who have not > > contributed in more than a month will retire to committers emeritus. > > Hopefully this will prompt our institutional leads to commit to public > > Matterhorn development. > > > > 4 (Proposal). We keep a list of committers and their organizations on > > the front project (or wiki, whichever's easiest) page. This will > > highlight those who are contributing. > > > > 5. To address B, I'm going to revive Adam Hochmans' habit of setting a > > developer meeting agenda ahead of time. Every week I'm going to call > > out a specific group of developers to come forward and explain what they > > are working on, and what is blocking their progress. This doesn't need > > to be 20 minutes, but it should be 5 to 10. > > > > 6. To address C, I'm going to start sending out emails containing a > > summary of the unassigned bugs for the current release. This will > > increase the visibility of these tickets so that developers become aware > > of them and address them. > > > > Please note the two proposals. Voting begins now, and lasts for 72 > hours. > > > > G > > > > _______________________________________________ > > Matterhorn mailing list > > [email protected] > > http://lists.opencastproject.org/mailman/listinfo/matterhorn > > > > > > To unsubscribe please email > > [email protected] > > _______________________________________________ > > _______________________________________________ > Community mailing list > [email protected] > http://lists.opencastproject.org/mailman/listinfo/community > > > To unsubscribe please email > [email protected] > _______________________________________________ >
_______________________________________________ Community mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/community To unsubscribe please email [email protected] _______________________________________________
