Re: [Wikitech-l] Roadmaps and getting and keeping devs
2011/2/13 Bryan Tong Minh bryan.tongm...@gmail.com: This has gotten better lately, WMF created a bugmeister position and the bugmeister tries to respond to most if not all bugs after being reported. We should definitely keep up with this and try to at least confirm every problem that is being reported. The difficult part I think is responding to every patch. I don't believe that we currently have the capacity to review those patches. (In fact we barely have sufficient capacity to review the contributions of our core developers!) I've also read one of the articles linked in the OP, and it got me thinking about the fact that we're not only bad at responding to bug reports (although bugmeister efforts are focused on that now), but also at responding to commits. In the preparations for the 1.17 release I've seen lots of commits that were several months old and only got reviewed because we decided to work on a release. Ideally, every commit would be reviewed within a few days of being committed, so the committer can still reasonably be expected to fix any issues with it. Not letting review get too far behind HEAD is also important for doing continuous integration, something I'm really gonna push for now that I'm closely involved with the saga around deploying a new version with about 15,000 new revisions. Getting things reviewed fast ought to be doable if we set up some kind of schedule where, say, 7 reviewers are each responsible for one day of the week (or 5 reviewers for 4 36-hour chunks and one 24-hour chunk, or take turns every 100 revisions, or ...) and reassign some of their revisions to others where specific expertise is needed. This is basically what we've been doing with the last 1.17 review sprint: Mark Hershberger divided up the review queue between 4 or 5 people using tags in CodeReview, and we would each go through our queue, review what we could, and reassign the rest. Bugzilla patches are another matter, yes, but I think making sure patches get reviewed can be a Bugmeister task. We get relatively few patches through Bugzilla these days anyway. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Roadmaps and getting and keeping devs
On 13/02/11 11:54, Roan Kattouw wrote: Bugzilla patches are another matter, yes, but I think making sure patches get reviewed can be a Bugmeister task. We get relatively few patches through Bugzilla these days anyway. Maybe once 1.17 is released, we should focus on the bugzilla patch queue and get it solved. Would probably keep us busy until June. Do we have any hack-a-ton planned? I can probably take a whole week day-offs to participate and solve them. -- Ashar Voultoiz ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Roadmaps and getting and keeping devs
Maybe we can make the bugathon part of the Berlin hackaton? On Sun, Feb 13, 2011 at 4:03 PM, Ashar Voultoiz hashar+...@free.fr wrote: On 13/02/11 11:54, Roan Kattouw wrote: Bugzilla patches are another matter, yes, but I think making sure patches get reviewed can be a Bugmeister task. We get relatively few patches through Bugzilla these days anyway. Maybe once 1.17 is released, we should focus on the bugzilla patch queue and get it solved. Would probably keep us busy until June. Do we have any hack-a-ton planned? I can probably take a whole week day-offs to participate and solve them. -- Ashar Voultoiz ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- a href=http://about.me/diederik;Check out my about.me profile!/a ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Roadmaps and getting and keeping devs
These have been circulating in the open source Twitterspere today. They struck me as apposite to discussions on these topics around MediaWiki. How to write a roadmap: http://blogs.gnome.org/bolsh/2011/02/07/drawing-up-a-roadmap/ How to grow your contributor community (and how to decimate it): http://www.codesimplicity.com/post/open-source-community-simplified/ - d. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Roadmaps and getting and keeping devs
On Samstag, 12. Februar 2011 at 17:55, David Gerard wrote: How to grow your contributor community (and how to decimate it): http://www.codesimplicity.com/post/open-source-community-simplified/ and imo, wikimedia fails at a lot of these points: *Quote: Respond to contributions immediately. This is what I think bugs me the most. There are heaps of bugs which have had patches attached for month or years. For newcomers, who maybe spent a lot of time on these, it's just rude to neither commit them nor explain why they can't be committed immidiately. *Create and document communication channels. This has been talked about before, and maybe it did indeed get it little better. Leo ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Roadmaps and getting and keeping devs
For the last months I have been going through Bugzilla and what strikes me is that we are not using it as efficiently as other communities do. In particular, there is little follow up to reported problems (as Leo mentioned as well). On the short term, I think we can have a bugathon to clean up the buglist a little bit and re-energize some community members: Have a bugathon where we label a lot of bugs as appropriate bugathon bugs that need either: a) test patch / update patch to recent svn version a) confirmation / replication of new / unconfirmed bugs We can provide a simple ready to go Wiki installation for people to use for bug triaging and that way we can re-energize developers and clean up some of the backlog of bugs. Is this something that we should be doing? On Sat, Feb 12, 2011 at 3:41 PM, Leo diebu...@gmail.com wrote: On Samstag, 12. Februar 2011 at 17:55, David Gerard wrote: How to grow your contributor community (and how to decimate it): http://www.codesimplicity.com/post/open-source-community-simplified/ and imo, wikimedia fails at a lot of these points: *Quote: Respond to contributions immediately. This is what I think bugs me the most. There are heaps of bugs which have had patches attached for month or years. For newcomers, who maybe spent a lot of time on these, it's just rude to neither commit them nor explain why they can't be committed immidiately. *Create and document communication channels. This has been talked about before, and maybe it did indeed get it little better. Leo ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Roadmaps and getting and keeping devs
Have a bugathon where we label a lot of bugs as appropriate bugathon bugs that need either: a) test patch / update patch to recent svn version a) confirmation / replication of new / unconfirmed bugs We can provide a simple ready to go Wiki installation for people to use for bug triaging and that way we can re-energize developers and clean up some of the backlog of bugs. Is this something that we should be doing? This is something we do at hack-a-tons. I don't remember the number of bugs smashed at the last one, but it was a decent number. I believe the next hack-a-ton is in Berlin, soon. I'm not sure if they have this planned. It's apparently GLAM focused (which excludes devs like me), so I'd imagine not, unless the bugs targeted are GLAM related. - Ryan Lane ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Roadmaps and getting and keeping devs
I think one way that non technical people can help is by trying to replicate bugs, if they follow the steps as described in the bugreport Do you get the same malfunction or not. That would be a great help as it weeds out invalid bugreports Sent from my iPhone On 2011-02-12, at 17:26, phoebe ayers phoebe.w...@gmail.com wrote: On Sat, Feb 12, 2011 at 1:11 PM, Ryan Lane rlan...@gmail.com wrote: Have a bugathon where we label a lot of bugs as appropriate bugathon bugs that need either: a) test patch / update patch to recent svn version a) confirmation / replication of new / unconfirmed bugs We can provide a simple ready to go Wiki installation for people to use for bug triaging and that way we can re-energize developers and clean up some of the backlog of bugs. Is this something that we should be doing? This is something we do at hack-a-tons. I don't remember the number of bugs smashed at the last one, but it was a decent number. I believe the next hack-a-ton is in Berlin, soon. I'm not sure if they have this planned. It's apparently GLAM focused (which excludes devs like me), so I'd imagine not, unless the bugs targeted are GLAM related. - Ryan Lane I'm curious: is there a way that non-technical people can help with sprints like this? Documentation-building, maybe? Something else? I'm interested in development sprints, bugathons etc that involve both technical non-technical people; I've been involved in a few and it's pretty fun. But I don't know how many useful ways non-programmers non-developers can help. -- phoebe -- * I use this address for lists; send personal messages to phoebe.ayers at gmail.com * ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Roadmaps and getting and keeping devs
On Sat, Feb 12, 2011 at 1:11 PM, Ryan Lane rlan...@gmail.com wrote: Have a bugathon where we label a lot of bugs as appropriate bugathon bugs that need either: a) test patch / update patch to recent svn version a) confirmation / replication of new / unconfirmed bugs We can provide a simple ready to go Wiki installation for people to use for bug triaging and that way we can re-energize developers and clean up some of the backlog of bugs. Is this something that we should be doing? This is something we do at hack-a-tons. I don't remember the number of bugs smashed at the last one, but it was a decent number. I believe the next hack-a-ton is in Berlin, soon. I'm not sure if they have this planned. It's apparently GLAM focused (which excludes devs like me), so I'd imagine not, unless the bugs targeted are GLAM related. - Ryan Lane I'm curious: is there a way that non-technical people can help with sprints like this? Documentation-building, maybe? Something else? I'm interested in development sprints, bugathons etc that involve both technical non-technical people; I've been involved in a few and it's pretty fun. But I don't know how many useful ways non-programmers non-developers can help. -- phoebe -- * I use this address for lists; send personal messages to phoebe.ayers at gmail.com * ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Roadmaps and getting and keeping devs
On Sat, Feb 12, 2011 at 9:41 PM, Leo diebu...@gmail.com wrote: *Quote: Respond to contributions immediately. This is what I think bugs me the most. There are heaps of bugs which have had patches attached for month or years. For newcomers, who maybe spent a lot of time on these, it's just rude to neither commit them nor explain why they can't be committed immidiately. This has gotten better lately, WMF created a bugmeister position and the bugmeister tries to respond to most if not all bugs after being reported. We should definitely keep up with this and try to at least confirm every problem that is being reported. The difficult part I think is responding to every patch. I don't believe that we currently have the capacity to review those patches. (In fact we barely have sufficient capacity to review the contributions of our core developers!) *Create and document communication channels. This has been talked about before, and maybe it did indeed get it little better. Being a volunteer, I believe that the staffvolunteer communication have greatly improved over the last couple months. I can't speak for the developernon-technical community communication though. We're obviously not there yet, but we are definitely improving. Bryan ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Roadmaps and getting and keeping devs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In article AANLkTi=nq2tookvgmhrxbegvr6fzxe1wzv9dbzde4...@mail.gmail.com, Ryan Lane rlan...@gmail.com wrote: Have a bugathon where we label a lot of bugs as appropriate bugathon bugs that need either: a) test patch / update patch to recent svn version a) confirmation / replication of new / unconfirmed bugs [...] Is this something that we should be doing? This is something we do at hack-a-tons. I don't remember the number of bugs smashed at the last one, but it was a decent number. I believe the next hack-a-ton is in Berlin, soon. Perhaps requiring people to travel to another country to participate in this is part of the problem. I don't doubt that real-life meetings are useful for Wikimedia Foundation employees and existing MW contributors, but it doesn't do much to encourage new people to join in. - river. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (NetBSD) iEYEARECAAYFAk1XJGEACgkQIXd7fCuc5vL5UgCfQGe4tQa61xOev8fzBmOosmc1 VE0Anie2oDODr9mU+jXE+tkANJnfjpY6 =dJKA -END PGP SIGNATURE- ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Roadmaps and getting and keeping devs
I believe the next hack-a-ton is in Berlin, soon. Perhaps requiring people to travel to another country to participate in this is part of the problem. I don't doubt that real-life meetings are useful for Wikimedia Foundation employees and existing MW contributors, but it doesn't do much to encourage new people to join in. We also plan to have two US-based hack-a-ton's a year, and I believe there is some form of one at Wikimania too. You don't always necessarily need to travel to another country to get to one. I don't disagree with your sentiment though. We should likely make these events easier to attend online. We already put in the effort to mark bugs before hand, and we all work on IRC while at the event, so I don't see anything stopping online participation from happening. The hack-a-tons usually don't have presentations, so that part isn't much of an issue. We can likely stream out anything that needs to be, if it comes up. I believe that in-person events are key for people to get to know one another, though. Maybe not everyone feels that way, but I definitely do. I've worked on MediaWiki for years, and I feel I know other community members much better since I've been meeting them in person, much more so than the years prior. The hack-a-tons may not be effective at bringing in new people, but I feel they are very effective at solidifying the current community that we have. - Ryan Lane ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Roadmaps and getting and keeping devs
Leo diebu...@gmail.com writes: *Quote: Respond to contributions immediately. This is what I think bugs me the most. There are heaps of bugs which have had patches attached for month or years. For newcomers, who maybe spent a lot of time on these, it's just rude to neither commit them nor explain why they can't be committed immidiately. This is one of the things I've been trying to do as the new Bugmeister. Every day, about 20-30 bugs are created. Especially in those cases where the bug reporter is not a MediaWiki developer or regular user of Bugzilla, I try to make sure that they hear back from me, even if it is just “Thanks for reporting this, I'll try to make sure someone looks at it.” But, to your specific complaint about patches submitted through Bugzilla, I like Diederik's suggestion: Have a bugathon where we label a lot of bugs as appropriate bugathon bugs that need either: a) test patch / update patch to recent svn version a) confirmation / replication of new / unconfirmed bugs In fact, although I've been focused on the 1.17 release, I've also been thinking about the 1.18 release. This would be a great way to start addressing the creeping normalcy[1] that people have experienced with MediaWiki. I definitely want to have one or two of these bugathons during the next release cycle. If there is enough interest, perhaps we can plan something for Berlin. The other thing that will help is making more releases more often. This is one area that I want to use my new role within the community: until now, no one has been expected to make sure MediaWiki releases are made “early and often” and we were all happy enough to focus on writing new code while making software relases someone else's responsibility. More frequent releases communicate vitality to software developers. [1] http://en.wikipedia.org/wiki/Creeping_normalcy -- Mark A. Hershberger Bugmeister Wikimedia Foundation mhershber...@wikimedia.org 717.271.1084 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
