Skip to content

GitLab Issue Bash Q2 2017

We will be holding the second Quarterly Issue Bash for the GitLab Community Edition tracker in June. The format of the event will effectively be the same as the GitLab Issue Bash Q1 2017

This issue exists to facilitate the organisation of the event, stir up interest, and contain the directions for participants.

Event Details:

Fantastic Issues and Where to Find Them

Closing of Issues

  • Identifying duplicates issues and mentioning a member of the team
  • Team member will triage and possibly close as a duplicate
  • (Non technical) Will need to be able to search through issues and identify duplicates
  • Attempting to reproduce labelled bugs in a test project on GitLab.com and mention a team member with the results of their investigation (suggesting labels, suggesting closure, etc)
  • Team member will triage and close if the bug is no longer reproducible
  • (Both Technical and Non technical) Some bugs are harder to reproduce than others, but the majority should be reproducible using a test project created on GitLab.com
Best place to start:
  • Not really a suggestion for finding duplicates. Duplicates could exist for any issue and we don't have any particular view that makes finding them easier.
  • Existing bugs view will help for determining if old bugs should be closed as non-reproducible or kept open
Best way to help out

Comment on issues about what you have found out and your suggestions for issues, whether to close or keep open and if you've found a duplicate, mention the issue ID. Mention a key contact so that the correct course of action can be taken

Categorising Existing Issues

  • Investigate unlabelled issues with the aim of providing a suitable label and mentioning a team member
  • Team member will apply suggested label
  • (Non technical)
Best place to start:
  • Unlabelled issues
  • These issues are all unlabelled and open, they haven't been triaged as of yet
  • These issues are listed in order of first raised, so some may no longer be valid, some will be old
  • These issues may contain interesting feature proposals or bugs that haven't yet been categorised
Best way to help out

Write a comment on the issue mentioning a key contact and the labels suggested using the label syntax ~label

Fixing known bugs and pain points or shipping existing feature proposals

  • Look into the issues labelled as ~bug , attempt to reproduce and provide a Merge Request to fix
  • Team member will label the issues and merge requests as needed and mention other team members that can help progress the original issue to closure
  • Some issues may just be filed under ~Documentation
  • (Technical and Non technical) Some bugs are easier to fix and may only require changes to documentation which can be done via the Web Interface, some are much more difficult to fix
  • Look into the issues labelled as ~"Accepting Merge Requests" ~"feature proposal" , understand the use case and create a Merge Request to provide the new functionality
  • Team member will label the issues and merge requests as needed and mention other team members that can help progress the original issue to closure
  • (Technical and Non technical) Some feature proposals are easier to write and may only require changes to documentation which can be done via the Web Interface, some are much more difficult to satisfy
Best place to start:
  • Existing bugs
  • These issues have all been categorised as bugs at one time or another
  • These issues are ordered by oldest updated first
  • These bugs may have been fixed and therefore the issues are no longer reproducible and should be closed.
  • These bugs may still stand and a contributor could pick up the issue and provide a fix in a Merge Request
  • These bugs will touch on all sorts of categories from Documentation to style fixes to frontend and backend fixes. There's plenty for everyone
  • Accepting Merge Requests - bugs
  • These issues have already been opened up for a ~"Community Contribution"
  • These issues have been categorised as a bug
  • These issues are listed in order of first raised
  • Accepting Merge Requests - feature proposals
  • These issues have already been opened up for a ~"Community Contribution"
  • These issues have been categorised as a feature proposal
  • These issues are listed in order of first raised
  • Ideal First Time Contribution issues
  • Ideal for new contributors!
Best way to help out

Submit a Merge Request with a potential fix for the issue and mention a key contact so that proper labels can be assigned. The normal review process for Community Contributions will then commence

Core and team members to action volunteer suggestions and findings

Community and comms

We will need to inform the community of the event to get as many people as we can involved:

  • Community comms
    • Blog post
    • Tweets
    • Announcement on the Forum

Iteration and Changes

This time we would like to make some changes to the format to line up with GitLab's values:

Collaboration

Communication Channel
Summary

This action was taken from feedback for the last event

We'd like to allow participants to work together and share ideas in real-time whilst taking part in the event, whilst making taking part in the event more social. This will aid feedback on reviews and questions about labelling and complex issues. Participants will be able to pitch questions to a larger audience to hopefully get an answer more quickly.

Actions

Results

Public Results Summaries and Open Source tools
Summary

We are all keen to close as many issues as possible and try to reach the goal of a mystery prize. We want to make it easier for participants to be able to query the participation data for the issue bash whenever they want to see how the event is progressing

Actions
  • Improve the events API before the next bash to easily query events data for the event period
  • Open source the scripts or tools used to gather such information so participants can help to build and improve the issue bash tooling

Efficiency

Improve the project labels and make clear the labelling process
Summary

This action was taken from feedback for a previous event

Many participants were involved with suggesting labels for existing issues. We'd like to cut down the number of labels and improve the descriptions so it's clearer what each label represents

Actions
Increase the number of Community Members involved in actioning participant contributions
Summary

More people on the contacts team will lead to contributions being actioned more quickly and gain better results

Actions
  • Find more people to be on the contacts team
  • Make it easier for participants to mention a contact
  • Add a group to mention rather than a list of individuals

Diversity

Everyone can Contribute
Summary

We hope that we are being as inclusive as possible with the Issue Bash. We aim to be inviting to, and to provide opportunities for, users of all skill levels to get involved with the project.

If you feel that we could be doing more to increase diversity during the Issue Bash, please offer your suggestions

Actions

None so far

Iteration

React to feedback every quarter
Summary

Listen to and integrate feedback from contributors to improve each quarterly event and increase participation

Actions
  • We'll start by carrying out these actions proposed in line with our values and take further action based on participant feedback after each event

Transparency

Publish the tools used to determine the prizewinners
Summary

We want to ensure that all participants feel that the way we pick prizewinners is fair

Actions
  • Publish the tools that we use to draw names for prizes
Edited by Mark Fletcher