October 18, 2018

Setting Up & Running A Bug Bash


This article describes how to setup and run a bug bash - the intended audience is a Topcoder copilot. To learn more about how to participate in a bug bash, please click here.

Account/Access Structure:

  1. Unless required, repositories will be private by default

  2. Create team/group based access to repositories

  3. Member group access includes:
         1. receive read/write access to repository
         2. ability to create tickets
         3. ability to self-assign tickets
         4. ability to add and remove tags from tickets
         5. repo user should equate/tie to platform user
         6. Manager group access includes:
         7. receive read/write access to repository
         8. ability to create tickets
         9. ability to self-assign tickets
         10. ability to create wiki pages
         11. administrative control over repo
         12. repo user should equate/tie to platform user
         13. requisite teams applied to groups of repos for visibility over other components of a project.

Challenge Setup:

  1. In your challenge spec, ask the community to post in the forum and request access to the project group by including their github or gitlab username - in some instances, users will be auto-enrolled into the git project depending on how it’s been setup.

  2. Create your challenge as a Code challenge. You should provide an overview of the app and advertise your project here. Provide link to SCM.

  3. Set “QA” as a Technology tag on the challenge.

  4. Add community member to the group (example name “Goliath National Bank Team”) with “Developer” access only. This allows them to create tickets, fork the repo, and create branches but will not allow them to touch protected branches. Note: this level of access is a concept from Gitlab that does not exist in Github currently. See https://gitlab.com/help/permissions/permissions.md

  5. Have member add challenge managers to their private branch as a master and reviews as reporter. Note: this level of access is a concept from Gitlab that does not exist in Github currently.

Submission Process:

  1. Require community members to fork the project at the feature branch to acquire the current code base. This will allow for concurrent challenge running as each branch is a separate challenge.

  2. Two options for gaining access to code are available.
         1. Require submissions of code by through a merge request. The only issue with this method is that the code can be viewed in a “diff” of the merge request. This is the preferred method, unless privacy is a concern use the second.
         2. Require that the managers & reviewers be added to the private fork as a member. This is not exactly the ideal automation but it does get around the visibility of the code in the merge request diff.

Review Process:

  1. Test pull/merge request submissions locally before accepting.

  2. If submission passes, accept merging into feature branch.

  3. If submission fails, reviewer can make comments directly against code or merge request ticket.


  1. Wikis should be utilized extensively as a central repository for project information.

  2. Types of information include:
         1. Project description
         2. Setup guides
         3. Reference materials
         4. “Bug Bash” instructions
         5. Challenge detail listings

Issues List

  1. Issues lists can be utilized for general bug tracking as well as “Bug Bashing”

  2. Members can be alerted to issue tickets by utilizing the @all/@organization/team-name mention

Bug Bashing Process

  1. Create the following tags on the repo:
         1. “_OPEN FOR PICKUP” denoting ticket is available to members to self-assign
         2. “_READY FOR REVIEW” denoting that a member has completed the requested work
         3. “_ACCEPTED” denoting managers have accepted ticket solution
         4. “_PAID” denoting ticket has been processed for payment
         5. “Priority X” where X is a value from 1 through 5 denoting triage priorities (1-Blocker through 5-Enhancement)

  2. Assign a priority label to tickets.

  3. Assign a dollar value to all tickets in the ticket title as a prefix.
         1. The dollar amount is based on scope and complexity.
         2. The purpose of the dollar amount is to create a value for tickets that can be driven up and down on demand.

  4. Mention @all members that a ticket is available for pickup.

  5. Members self-assign tickets

  6. Only one ticket is allowed per member at a time.

  7. If a member has not submitted within 24hrs, the member forfeits the ticket and the ticket is unassigned.

  8. Member labels ticket as “_READY FOR REVIEW” once their submission is ready.

  9. After reviewing submission the manager/reviewer marks the ticket as “_ACCEPTED”

  10. After the manager has accepted the submission and process payment, the ticket is labelled “_PAID” and payment reference placed as a comment on the ticket.

Group 9
Group 9

Recommended for you

What is a Bug Bash?

Overview The primary objective of a bug bash is to fix a number of issues in either a subset of code, or an en...
Read More E4627031-A283-4694-8843-C0F351FBA3F8

Managing Tasks

Topcoder is introducing the concept of tasks to the platform. This will be incrementally rolled out and integr...
Read More E4627031-A283-4694-8843-C0F351FBA3F8

What is QA?

One of the key drivers of Digital Transformation within large organizations is the mass consumerization of tec...
Read More E4627031-A283-4694-8843-C0F351FBA3F8