Helping Bugzilla Help Newcomers Help Mozilla Help Users

October 13, 2011 § 10 Comments

tl;dr

We can make Bugzilla more newbie-friendly.

edit Thanks for pointing me to mentored bugs, Josh!

The context

Earlier today, a discussion got me thinking about how we can lower the entry barriers for people who want to contribute to Mozilla in a technical or semi-technical way but do not know where to start – by “technical or semi-technical”, I have in mind developers, web developers, translators, and more generally people who need to commit some form of patch to any of the Mozilla subprojects.

There are many things that we can improve, but for this post, I would like to concentrate on Bugzilla tweaks that I believe could be useful. These tweaks come from a simple remark: for all contributors Bugzilla is, in fact, a form of contribution console. Unfortunately, for the moment, I see the following problems:

  • Bugzilla doesn’t help newcomers find easy entry points;
  • Bugzilla doesn’t guide newcomers towards their first patch;
  • Bugzilla doesn’t help old-timers help newcomers.

So, let’s see how we could improve Bugzilla.

Making newcomers visible and encouraging old-timers to help them

I believe that the first thing we need to do is to make sure that newbies are more visible to old-timers. For this purpose, we can provide an account attribute “I’m a beginner, please be gentle”, which appears in the profile, ticked by default, and remains there until unticked. Every message, attachment or patch provided by a newbie is clearly labelled as such.

This label may come with a link to the wiki with suggestions for old-timers wanting to help the newbie.

Similarly, we can encourage old-timers to adopt a newbie. For this purpose, we can provide an account attribute “Adopt a newbie”, with a list of accounts. Every message, attachment or patch provided by an adopted newbie is automatically tracked by the adopter.

Note As far as I understand, these features are already essentially implemented. I’m just proposing a small tweak.

Having Bugzilla tell stories

Bugzilla is a nice place for reporting bugs and discussing how to solve it. I propose a simple tweak to make Bugzilla tell the story of a patch. Let me show you one possible manner of doing this:

Each of these link should help a newcomer on one step towards getting a patch submitted and accepted:

  1. “Help me set up for contributing” points to some of the wiki pages we already have containing project-specific setup documentation. For Mozilla coding bugs, this explains how to build Mozilla. For localization bug, this explains how to setup whichever tools are required, etc. This is set up on a per-component basis.
  2. “Help me contact the developers” points to the component-specific wiki page with all the contact information (IRC channel, forum, mailing-list, module owner e-mail address, etc.).
  3. “Help me find project doc” points to the project-specific wiki page with all the documentation.
  4. “Help me submit a contribution” points to a beginner-oriented wiki page with the information on submitting. For mozilla-central, for instance, beginners should be able to find the two lines that will let them export everything they have done as one hg patch.
  5. “What’s next” points to a wiki page detailing the submission approval process, the various forums, IRC channels, etc. to which the contributor can participate.

This is for beginners. As you may have seen, there is another toolbar, designed for experienced developers/community members:

This toolbar is designed to keep track of activity on bugs that the user follows:

  1. “Unconfirmed” lists the number of UNCO bugs followed by the user.
  2. “In progress” lists the number of NEW bugs followed by the user.
  3. “Review” lists the number of patches pending review in bugs followed by the user.
  4. “Mentoring” lists the unread messages and patches submitted by newbies adopted by the user.

Clicking on each link points to a bugzilla search of the corresponding bugs.

Making easy bugs easy to discover

New contributors need to find good entry points. For this purpose, we have project-specific lists of good first bugs. However, at the moment, the lists I could find are both hard to discover and unmaintained. So, let’s integrate this in Bugzilla. As it turns out, it’s quite easydone already (and better than what I suggested initially).

I suggest adding two tags: “easy” and “average”. Every bug can be annotated as “easy” if a developer believes that it’s a good first bug or “average” if a developer believes that it’s a bug that requires some experience but no architectural overview.

Once this is done, we can link from all our wikis and contributor engagement pages to Bugzilla searches with all the “easy” and all the “average” bugs, both project-wide and by component.

Submission add-on

This one is more of a dream. I believe that, at some point, we could develop an add-on that can be installed directly fro the Bugzilla toolbar, and whose role is to provide a wizard to help users:

  • install the appropriate source management tool;
  • once the tool is installed, submit a patch for review.

Initially, this add-on covers only mozilla-central. Later, upgrades to this add-on and/or project-specific add-ons may be added for projects not covered by mozilla-central (typically projects hosted on github).

Inspiration: want to do better than (otherwise excellent) github “pull request” :)

Badges!

  • First bug report tagged “new”? Earn a badge!
  • First patch submitted? Earn a badge!
  • First patch accepted? Earn a badge!
  • Same thing for the marks of 10, 50, 100 …

Any thoughts?

Ok, this lists the tweaks that I can think of to improve newbie experience with contributions. What do you think? Any way we can make this better?

About these ads

Tagged: , , , , , , , , , , , , , , , , , , , , ,

§ 10 Responses to Helping Bugzilla Help Newcomers Help Mozilla Help Users

  • glob says:

    thanks for thinking about how to make bmo better!

    as noted the “new comer” system is already in place, and is automatic. i don’t like the idea of it being something which someone manually has to toggle. the same system also automatically identifies someone’s first patch. “adoption” can be achieved with the existing “user watching” facility; so we shouldn’t need any bmo dev work to achieve this :)

    the toolbars idea is interesting .. file a bug in the bugzilla.mozilla.org product and we can start fleshing it out. running 4 queries on each page to get the bug counts unfortunately probably won’t happen due to the impact this would place on the servers, but i love the idea of the new firefox contributor toolbar.

    for bugzilla development we put “good intro bug” into the whiteboard to identify bugs which new contributors can target (http://bit.ly/oJgcas). adding keywords would be another method of tagging bugs; i don’t think we need another field to track this specifically. i’m a bit surprised to see this isn’t happening in other products :)

    badges are interesting (stackoverflow anyone?). a precursor to that would be a stats page for each login (showing counters for bugs, comments, patches, reviews, etc).

    • yoric says:

      as noted the “new comer” system is already in place, and is automatic. i don’t like the idea of it being something which someone manually has to toggle. the same system also automatically identifies someone’s first patch.

      Yes, the only tweak I suggest is not turning it off automatically. I tend to believe that “first patch” might be a little early.

      “adoption” can be achieved with the existing “user watching” facility; so we shouldn’t need any bmo dev work to achieve this :)

      Yeah, it’s probably essentially a documentation stuff and/or a tweak to the preferences panel.

      the toolbars idea is interesting .. file a bug in the bugzilla.mozilla.org product and we can start fleshing it out.

      I’ll do that.

      running 4 queries on each page to get the bug counts unfortunately probably won’t happen due to the impact this would place on the servers, but i love the idea of the new firefox contributor toolbar.

      Yeah, that’s what I feared. Perhaps we can easily obtain the same feature with a custom search saved as rss. We’d just have to suggest using it.

      for bugzilla development we put “good intro bug” into the whiteboard to identify bugs which new contributors can target (http://bit.ly/oJgcas). adding keywords would be another method of tagging bugs; i don’t think we need another field to track this specifically. i’m a bit surprised to see this isn’t happening in other products

      Well, if there’s a similar mechanism for other products, I haven’t found it.

      badges are interesting (stackoverflow anyone?). a precursor to that would be a stats page for each login (showing counters for bugs, comments, patches, reviews, etc).

      Should I file a bug for this, too?

  • We may be able to help with the “stats” page and the badges with @berkerpeksag. I don’t know bugzilla much but if it provides some kind of API(A JSON-REST combination would be great) to aggregate user stats it will be easy. We may even include sparklines as in GitHub. If there isn’t an API, I am pretty used to parsing websites to extract information =)

  • I prefer abandoning concepts like “easy” and “average”, which can be fairly subjective. The current concept of mentored bugs that is being promoted is that bugs that are understood well, have a solution that is desired and won’t get lost in politics are good candidates for new contributors to work on with the assistance of a dedicated mentor.

  • Loic Dachary says:

    In a recent contribution to libreoffice, I approached the problem with a pure jQuery based client accessing bugzilla thru a reverse proxy. The result is at https://www.libreoffice.org/get-help/bug/ and a post mortem of the development can be found at http://dachary.org/?p=886

    Of course the better general solution is to extend bugzilla. I specially like the badges : introducing leveling and gameplay to bug handling is a great idea.

    However extending bugzilla or even upgrading bugzilla to a version providing the REST API is sometime not an option. That was the case of libreoffice and I believe that in these cases a pure web client can prove useful.

  • [...] is a nice discussion of this idea on a post on David’s blog: “Helping Bugzilla Help Newcomers Help Mozilla Help Users“. There are also some other fun ideas there such as using badges for [...]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

What’s this?

You are currently reading Helping Bugzilla Help Newcomers Help Mozilla Help Users at Il y a du thé renversé au bord de la table.

meta

Follow

Get every new post delivered to your Inbox.

Join 33 other followers

%d bloggers like this: