Hi all,
While I don't have a vote, I'll add my opinions: Firstly, I think it's great to (a) surface the actual developer time commitment, and (b) be disciplined about JIRA practices re assignment. However, as the number of committers (hopefully) grows, especially across time zones, it's not realistic to expect all committers to attend developer meetings. Also as the manager of developers at UCT who work across several projects (Opencast, Sakai and some smaller systems and tasks), I can say that it's not realistic to expect every developer to be active on Opencast every month. At times we'll have particular deadlines which either increase our Opencast activity (e.g. leading up to the development of a new Matterhorn release locally we might be more active in bugfixing) or decrease it (if we have short-term priorities for another project). So I'd suggest setting the "emeritus timeout" to more like a year. Lastly, the resources that institutions have to commit to Matterhorn development goes down when some of that energy gets taken up by production issues (e.g. bugs and performance problems) in the version that they're running. For example right now UCT has a set of reliability issues with our CAs that we're exploring, and our developer attention is focused there, but there's not a lot of community effort right now in bugfixing to support production releases (as opposed to new feature development). So definite endorsement for your point 6 below. Regards Stephen Stephen Marquard, Learning Technologies Co-ordinator Centre for Educational Technology, University of Cape Town http://www.cet.uct.ac.za Email/IM/XMPP: [email protected] Phone: +27-21-650-5037 Cell: +27-83-500-5290 >>> Greg Logan 09/11/12 6:25 PM >>> 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 ### UNIVERSITY OF CAPE TOWN This e-mail is subject to the UCT ICT policies and e-mail disclaimer published on our website at http://www.uct.ac.za/about/policies/emaildisclaimer/ or obtainable from +27 21 650 9111. This e-mail is intended only for the person(s) to whom it is addressed. If the e-mail has reached you in error, please notify the author. If you are not the intended recipient of the e-mail you may not use, disclose, copy, redirect or print the content. If this e-mail is not related to the business of UCT it is sent by the sender in the sender's individual capacity. ### ________________________________ UNIVERSITY OF CAPE TOWN This e-mail is subject to the UCT ICT policies and e-mail disclaimer published on our website at http://www.uct.ac.za/about/policies/emaildisclaimer/ or obtainable from +27 21 650 9111. This e-mail is intended only for the person(s) to whom it is addressed. If the e-mail has reached you in error, please notify the author. If you are not the intended recipient of the e-mail you may not use, disclose, copy, redirect or print the content. If this e-mail is not related to the business of UCT it is sent by the sender in the sender's individual capacity. _______________________________________________ Matterhorn mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn To unsubscribe please email [email protected] _______________________________________________
