Reclama

Intro

Reclama (codename) is a tool that hosts bug sprints taking place at events.

Specifications

• A straight-forward interface displaying hand-selected good first bugs, ready to be worked on
• Next to bugs, prizes should be displayed.
• Viewing from mobile devices should be also accounted for.
• Public access to all content. Ability to edit and add events on selected accounts (hardcoded for v1)
• The interface has to be properly Mozilla branded (high visibility and promotion in an event)
• It needs to be future-proof for event to come (easily add new events and/or bugs after deployment)
• Solution URL should be short and easily memorable and digestible.
• v1 It needs to be delivered before 31-Jan-2015 09:00 CET (start of FOSDEM 2015)
• A report should be compiled with usage statistics and impact analysis for the experiment (see below)

Roadmap

Version 1

V1 was developed right before FOSDEM 2015 met all initial requirements above. Here is a detailed report:

Version 2

TBD specifications and timeline with stakeholders.

Bugs/code

• Code can be found here github.com/mozilla/reclama
• Bugs and issues can be found in our issues

Usage

If you want to have a Bug Sprint event setup for your event, the following steps need to be taken:

• Gather the list of bugs that you want to work with. This should involve outreach to engineering teams at Mozilla, who would like contributions to their bugs. The general guidelines (not all need to be met) for choosing bugs are:
  • Good first bugs
  • Bugs that have good impact on the project
  • Developers can work unsupervised
  • Bonus points if setting up the environment for working on the bugs is not too complicated and is well documented
• Ask the team providing the bugs to have someone on call during the event to monitor the bugs for developers that comment and ask questions in Bugzilla.
• Contact Brian or Pierros on the Participation team to setup the event for you and populate it with the bugs you want added, and the incentives you many have for getting bugs fixed.
• Setup a Discourse thread for the sprint, to monitor for support during the event. Here is an example. Use the Reps Events category. Monitor the thread during the event and try to give prompt answers.
• Work on a followup strategy for bugs that have been worked on during the event. This could include things like:
  • Ensuring momentum on bugs started during the event, e.g. encouragement, making connections, code review, and so on.
  • Recognition of contributors

Contact

See the Participation Infrastructure group for more details.