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:
- Dates: Saturday June 3rd to Sunday June 4th
- Contacts:
- @markglenfletcher
- @haynes
- @blackst0ne
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
- We'll be using the official Gitter channel for this
- https://gitter.im/gitlabhq/gitlabhq
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
- Improve the process for labelling issues in the Handbook
- Improve descriptions for labels for the GitLab-CE project
- Make it easier to search through labels
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