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.
Unless required, repositories will be private by default
Create team/group based access to repositories
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.
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.
Create your challenge as a Code challenge. You should provide an overview of the app and advertise your project here. Provide link to SCM.
Set “QA” as a Technology tag on the challenge.
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
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.
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.
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.
Test pull/merge request submissions locally before accepting.
If submission passes, accept merging into feature branch.
If submission fails, reviewer can make comments directly against code or merge request ticket.
Wikis should be utilized extensively as a central repository for project information.
Types of information include:
1. Project description
2. Setup guides
3. Reference materials
4. “Bug Bash” instructions
5. Challenge detail listings
Issues lists can be utilized for general bug tracking as well as “Bug Bashing”
Members can be alerted to issue tickets by utilizing the @all/@organization/team-name mention
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)
Assign a priority label to tickets.
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.
Mention @all members that a ticket is available for pickup.
Members self-assign tickets
Only one ticket is allowed per member at a time.
If a member has not submitted within 24hrs, the member forfeits the ticket and the ticket is unassigned.
Member labels ticket as “_READY FOR REVIEW” once their submission is ready.
After reviewing submission the manager/reviewer marks the ticket as “_ACCEPTED”
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.