He has been doing it for a while now and this interview may give you an idea why having a bugmeister is a great idea.
Enjoy,
GerardM
Can you explain what a bugmeister does
The main idea of a bugmeister, is clear from the posted job opening. This basically says that the bugmeister acts to bring the community's issues to the attention of WMF Project Managers and Developers. In addition to making sure the community's needs are heard, I've also worked recently to get the developers from the community involved in WMF activities. For example, I'll be hosting a fund-raising-focused triage in a few weeks where community input is wanted.
There seems to be more work then can be done by one bugmeister, is it true that by focusing on what needs the most tender love and care, you pick from the low hanging fruit ?
There are a lot of bugs in Bugzilla (over 6000 open issues right now) so I admit that bug-solving is driven somewhat by the squeaky wheel since those are the issues the community has shown the most interest in. I do want to chew through those other bugs but I think that focusing on the new bugs and most-often referenced old bugs will get a lot of these bugs handled.
WMF is very much into agile development, is a bug triage something that you do at the beginning or at the end of a sprint
Good question. I'm not sure I have an answer, but let me try.
Part of the purpose of triage -- at least how we're using it at the WMF -- is to understand problem reports and how to solve them and, after that, to assign them to a team or a person to work on.
So, as far as I understand sprints, triage would happen at the beginning.
Identifying and assessing the new bugs is what I understand you do. How does this fit into the process of fixing bugs
This varies with how high a priority the bug gets. For a quick overview of the time-line of my involvement time-line see the documentation on MediaWiki.org.
For example, bugs that are "highest" priority get very close attention. "high" priority bugs less so, and so on.
Every week there are more new bugs then there are bugs that are marked as fixed, how significant is this?
First, the weekly bug report isn't completely accurate -- it has some bugs. For example, I noticed recently that it had reported 594 bugs created in one week when a query shows only 122 were created that week.
Second, it is normal for projects with open bug reporting tools to have more bugs created in a given period than closed. I'm having trouble finding the report at the moment, but I recall seeing Mozilla Firefox had more bugs opened in a year then closed.
There is a perceived lack of people working on the review of software, can you comment
Over the past year Rob Lanphier has worked to get more people reviewing the code since, yes, we had too few people doing code review. We're in a lot better position now, but we still do not have the resources to review every bit of code that is in subversion. I'd rather make the code repository and code distribution available to anyone who wants to extend MediaWiki, since this is better than telling people "We can't review your code, so it isn't welcome!"
As an example of how code review has gotten better, Rob Lanphier and I have been doing a lot of work on getting code reviewed faster and code marked FIXME fixed faster as we ramp up to a 1.18 deployment. This is a big pain point since we want to make more frequent releases of MediaWiki and become, as you pointed out, more agile. And we don't want to release un-reviewed code.
I think, though, that if you look at the way FIXMEs have been resolved, or how new revisions have been reviewed, that you'll see some very good trends. In the past few weeks we've really been driving unreviewed code down pretty hard. I'm confident that we can continue to keep unreviewed code low.
Code not written by WMF employees is certainly reviewed -- especially if it is going to be deployed on the site or released as part of MediaWiki. Since we only have limited resources, we cannot review all code in our Subversion repository.
For example, we host Semantic MediaWiki and extensions, but this code is not used on any Wikimedia website and is not distributed as part of MediaWiki, so, in order to make sure that the code we do release reviewed, we have to ignore Semantic MediaWiki for the most part.
An example of MediaWiki code that is not used on the cluster, but that is reviewed is the new Installer for MediaWiki or code that supports databases other than MySQL (such as PostgreSQL). But, when it comes to Database code we're somewhat limited in our ability since we're so focused on MySQL, so we are looking to recruit volunteer reviewers who use and are familiar with the other databases that MediaWiki can use to help review this code.
Siebrand indicated that the presence of people from many disciplines was why the recent i18n bug triage was so successful. How does this mix with the small teams typical of agile?
Triages are more successful when more people are involved, true. Since a basic part of the Bug Triage, at least in the way I've been running them, is open community involvement -- I hold the triages on IRC and everyone is invited -- I don't think we're limited by small teams.
What is the measure of your success; is it in the volume of work done on bugs or is it in a changed way or working of the developing community or is it a mix of things
I think it is still too early to answer that question definitively. I'm actually working with a researcher to find out what sort of metrics we can find in the bug database to draw good conclusions about community involvement, # of bugs solved, and the like.
A function like a bugmeister seems far removed from the community editing on the projects, do you and how do you keep informed on what happens in the projects
I work with different community members to enable editing on the projects. Extending the functionality of a project like we did with the Google News Site Maps (GNSM) extension on wikinews is a big part of that.
This coming Wednesday, I am having a WikiBooks-focused triage with some people from that community that I met in the Collection extension triage. During this time we'll be able to find out how we can help their project succeed more.
What is your favourite MediaWiki project, what is the most challenging project
I admit a soft spot for WikiSource, but this is mostly because I think we could use it to provide a community-driven replacement for ReCaptcha. Google is using ReCaptcha to help the New York Times scan in old newspapers, but, as far as I can tell, they aren't making the result publicly available. I think we can do better.
Thanks,
Mark.
No comments:
Post a Comment