Re: Policy for non-responsive maintainers
If you are not in a hurry to get this discussed, I propose wait until we finish we 0.98 (one month aprox) Right now, all the people we want be involved in this discussion, are too busy (me too). About the summer young hackaton in Uruguay, I take your word. Gonzalo On Wed, Oct 31, 2012 at 2:16 PM, Bernie Innocenti ber...@sugarlabs.orgwrote: +sugar-devel@ On Wed, 2012-10-31 at 01:06 -0300, Gonzalo Odiard wrote: Hi Bernie, I think we should discuss this proposal openly on sugar-devel, and while I agree in the need of have a Non Responsive Maintainer Policy, I don't agree with part of this proposal. Ok, copying the Fedora policy was just a way to start the discussion. I don't mind if our policy ends up being substantially different. What's important is stating clearly what a volunteer is supposed to do if they want to take over an unmaintained activity. For what is worth, the procedure could be as simple as ask Gary and Gonzalo on IRC. Discussing on sugar-devel@ is good, but make sure that the thread eventually converges to a decision (which is probably up to you and Gary). From my experience, we have two situations clearly separated, most of the orphaned activities have been orphan for a long time, in cases, years. Other case is a activity with a temporary busy maintainer, like Aleksey now, busy with SugarNetwork stuff. The first case is not a problem, any policy will be ok, I am more worried about the second case, were 2 or 3 weeks is a short time. With the actual situation, if who request maintainership is not a actual maintainer, I think should be good if some member in the community help him at least a time, in fact, Walter, Gary and me have rescued a lot of activities. Nice. Why don't you go ahead and update the wiki page I wrote to reflect the current practice and then ask for comments on sugar-devel@ ? In a ideal world, co-maintainers should be a solution to this problem, and we should encourage more co-maintainership. Hmm... Not sure about that. My experience when there are multiple owners is that nobody feels it's their duty to respond to bug reports, etc. Sometimes there's only one active owner and all the others are just emeritus maintainers. Multiple committers is great, but I suggest personal accountability for each activity. Labeling code as unmaintained is far better for users than creating false expectations with multiple co-maintainers who don't actually have time to support the code. In the real world, we are few developers. May be the involvement of more young hackers, helps. What can we do to help this kids? If you ask me, I would spent some money to organize some summer young hackaton in Uruguay to start. (I know is off topic, but is something to think about) Very nice idea. If you could organize the event, I'd be interested in helping with fundraising for the travel expenses. On Tue, Oct 30, 2012 at 7:48 PM, Bernie Innocenti ber...@sugarlabs.org wrote: Gary, this is the result of a conversation on #sugar regarding having a clear procedure for people who would like to take over orphaned activities. The current proposal is inspired from the Fedora policy, just shortened to 2 weeks as per Walter's request. If it still looks too laborious, we can cut it down a bit further. Or feel free to forward to sugar-devel@ if you wish to discuss it with everyone. On Fri, 2012-10-26 at 15:31 -0700, Bernie Innocenti wrote: As discussed today on IRC: http://wiki.sugarlabs.org/go/Activity_Team/Policy_for_nonresponsive_maintainers How does it look? -- Bernie Innocenti Sugar Labs Infrastructure Team http://wiki.sugarlabs.org/go/Infrastructure_Team -- Bernie Innocenti Sugar Labs Infrastructure Team http://wiki.sugarlabs.org/go/Infrastructure_Team ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Policy for non-responsive maintainers
On Wed, Oct 31, 2012 at 1:27 PM, Gonzalo Odiard gonz...@laptop.org wrote: If you are not in a hurry to get this discussed, I propose wait until we finish we 0.98 (one month aprox) Right now, all the people we want be involved in this discussion, are too busy (me too). About the summer young hackaton in Uruguay, I take your word. I am sympathetic to the too busy to bikeshed policy discussions agrument, with one exception, the long-abandoned activities. What's important is stating clearly what a From my experience, we have two situations clearly separated, most of the orphaned activities have been orphan for a long time, in cases, years. It is precisely the abandonware in ASLO and d.l.o/git that I would like to get GCI students (including especially those from Uruguay) engaged in rescuing and bringing up to a reasonably current standard (GTK3, i18n, olpcgamessugargames, touch?, etc.) In the real world, we are few developers. May be the involvement of more young hackers, helps. What can we do to help this kids? If you ask me, I would spent some money to organize some summer young hackaton in Uruguay to start. (I know is off topic, but is something to think about) Very nice idea. If you could organize the event, I'd be interested in helping with fundraising for the travel expenses. Yes, our developers are very, very busy developing. It is hard to ask any more of them, but nonetheless, I want to appeal to all members of the Sugar Community to take part in developing tasks for GCI and mentoring them. This is not a grand project like a GSOC, these are meant to be tasks that would take an experienced developer a few hours to do themselves. I am aware that in many cases, people will feel that it would be more efficient to wait and tackle the task themselves, but I agree with Walter that engaging with young developers is central to the high-ceiling aspect of the Sugar mission. As Gonzalo points out, it is also crucial to building our small contributor pool into a larger group. As nice as it would be to wait for a less busy time (like the summer), the reality is tha GCI is running now and Sugar Labs should not fail our existing young contributors by not putting our best efforts into succeeding with our GCI application, which would potentially give them a chance at a Grand Prize trip to the Googleplex. Think what that could mean to a young kid from Uruguay for a moment. Please read teh GCI FAQ: http://www.google-melange.com/gci/document/show/gci_program/google/gci2012/help_page Please take some time to record some half-baked ideas for tasks on the Brainstorming page: http://wiki.sugarlabs.org/go/GoogleCodeIn2012/GCI2012_Brainstorming More importantly, take some time to flesh out one or more specific tasks from any of the general cases described on the Brainstorming page into it's own task wiki-page linked from the main tasks page: http://wiki.sugarlabs.org/go/Google_Code-In_2012 We really need some additional ideas in the QA category. We are supposed to have at least 5 tasks in each of the categories as part of our application to GCI, and we need these this week if possible as winning organizations will be annopunced Nov 12th. From the application: Please provide a link to your tasks page. This is one of the most important parts of your application as it lets us see what type of work you plan to have the students work on for Google Code-in. Please be sure to include at least 5 tasks from each of the 5 categories. Please help us improve our GCI application by working on developing tasks for our application. cjl ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Policy for non-responsive maintainers
On Wed, 2012-10-31 at 14:27 -0300, Gonzalo Odiard wrote: If you are not in a hurry to get this discussed, I propose wait until we finish we 0.98 (one month aprox) Right now, all the people we want be involved in this discussion, are too busy (me too). There's no particular hurry. Actually, I brought up this particular issue just to make a more general point: we should codify our existing practices in the wiki for the benefit of new and existing contributors. Being swamped by an unclear process can be quite frustrating for a volunteer who just wants to get things done. About the summer young hackaton in Uruguay, I take your word. Glad to help, although it's unlikely that I'll be able to join in. -- Bernie Innocenti Sugar Labs Infrastructure Team http://wiki.sugarlabs.org/go/Infrastructure_Team ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel