Session
- Track: People and Processes
- Topic: Integrating contributions from other teams or volunteers
Description
What are current practices to include contributions (code patches, feature requests ...) from other teams or individuals in own team processes and workflows? What worked and what didn’t work in the past, and why? Let’s learn from each other and explore new ideas and improvements for processes, methods and workflows around contributions to own projects.
Questions to answer and discuss
To get a rough overview over the thing that we could try to address in the session, let's look at some key questions below.
Question:
( for Example: ) How can we make sure, that contributions are initially addressed? How can we make sure, that contributions do not get “lost” in an unknown state over time and just build up? How can we make sure, that existing / old contributions are addressed?
Significance:
Product management, backlog grooming, making sure that others gets feedback.
Question:
( for Example: ) How can we make sure, that there are people responsible for a code base / projects? How can we make sure, that contributions are noticed by the people responsible?
Significance:
Have team individuals involved!
Question:
( for Example: ) How can we make sure, that contributors know where to contribute what? How can we make sure, that contributors know how contribute? How can we make sure, that processes around contribution and their integration are known and transparent to contributors?
Significance:
Communicate with others and be transparent about your team habits / process.
Related Issues
Remotely related
- T200987: Set up volunteer code review queue
- T78768: Agree on and implement actions to prioritize code review of patches submitted by volunteers
- T85590: Maximize volunteer/staff engineer engagement in MediaWiki software projects
- T114419: Event on "Make code review not suck"
- https://www.mediawiki.org/wiki/Code_Review/Office_Hours
Session Style / Format
Directed unconference
5 minutes intro by session leads, presenting the format and the three topics.
Split in three groups, each discussing topics for 10 minutes including summarizing the discussion. Think about it as preparing an elevator pitch.
Regroup, each group will present the result of their findings and ideas. Roughly 5 minutes for each group.
Session ends listing actions and ideas to follow up with.
Slides https://docs.google.com/presentation/d/1PEQvnJIENW7oFCma1Jpel6ycR_fLGHGVWZgdwOE8wis
Post-event summary:
We identified several things that could be done to answer the questions of this session. Depending on the scope of these actions they could be implemented on a project- or team-level individually or would lead to some general additions of features in our tools ( like review bots adding guidance tips for new contributors ).
Post-event action items:
The notes below is already a pretty condensed, structured list of things that could be done in the different areas affected.
Wikimedia Technical Conference
Atlanta, GA USA
November 12 - 15, 2019
Session Name / Topic
Integrating contributions from other teams or volunteers
Session Leader: Antoine + Fisch; Facilitator: physikerwelt; Scribe: Chris
https://phabricator.wikimedia.org/T234662
Session Attendees
TheDJ, Birgit, Bryan, Timo, Stephen, Kosta, Daniel, Gergo, Volker, Sam, Daren, Cindy, Niklas, Brooke, Andre, TPT, Cormac
Notes:
- Introduction
- Fisch - Contributors topic is very broad - is it Phabricator, users, skins, editors? - We're wanting to focus on that.
- The session will deal with three main questions in that area and we will break into three groups, each of them to discuss each of the questions
- We already had similar sessions in the past ( e.g. at DevSummits ), some ideas where formulated there. Here's brief summary of ideas from last time:
- Code review office hours
- Set up volunteer code review queue (T200987)
- this idea still has capacity and workflow issues
- How to prioritize code review of patches submitted by volunteers
- especially T78768#996750
- Gerrit cleanup day T88531
- Ownership list ( https://www.mediawiki.org/wiki/Developers/Maintainers )
- Code review wrangler (from "Make code review not suck" T114419)
- You can come up with new idea or expand/elaborate on existing
- Please come up with at least one action item - next steps to make this happen
[the audience now breaks up into three groups to discuss the following questions]
[each group then had someone present a summary. Presenters: Andre Klapper, TheDJ, Bryan Davis]
- 1) How to improve the workflow around contributions?
- Overview of the contribution process: There is a long way from the idea of a new feature or the discovery of a bug to the appearance in production. To make this process more transparent and better traceable for contributions from team outsiders we suggest to
- Create a review checklist when submitting patch? (like Github review templates ?)
- Encourage CONTRIBUTING.md files in repositories and surface this information with ReviewerBot / NewcomerBot that automatically adds that information to new patches ( or even tickets? )
- Have a workflow for patches and a visual guide showing at which point your patch are and which actions are still required. This will ultimately help volunteers to find where they are in the process or why their contribution is stuck
- Public in context discovery of code review dashboards: contributors should get the same view on open patches as reviewers do. That way, contributors are more aware of how contributions get processed. Currently this is not discoverable, URL has to be manually crafted / exposed. Also, reviewers may Etherpad?
- Create a review checklist when submitting patch? (like Github review templates ?)
- Overview of the contribution process: There is a long way from the idea of a new feature or the discovery of a bug to the appearance in production. To make this process more transparent and better traceable for contributions from team outsiders we suggest to
- Form a team that's job is to triage patches and tasks, fix smaller issues and coordinate larger issues with other teams
- Should have a few engineers and a PM
- 2) How to create responsibilities for code and projects?
- Ownership
- Define classes of ownership (e.g., "active maintainer", "security fixes only")
- Set expectations and best practices for these roles, communicate them
- Clearer ownership visibility
- Better product road-mapping
- Having better published documentation on what we're interested in having people help with. Help with prioritization
- Define classes of ownership (e.g., "active maintainer", "security fixes only")
- Rewards for teams that support contributions
- Publish metrics + set quotas in teams goals
- Promote what metrics we do have and make more granular
- Making some team metric goals (the "performance" of the team should also be evaluated on the amount of code review they performed)
- Publish metrics + set quotas in teams goals
- Automation
- For new contributors not only detect when they create a patch, but invite them to create a Phabricator ticket. Automatically assign tags and teams based on files touched.
- Staleness auto-closing of issues
- Auto-close patches that have set for some period of time. Example: a patch that is two years old, you do not know what to do with it
- ( includes adding a message for the reasons why this was closed and a hint that it could be re-opened any time )
- Ownership
- 3) How to give good guidance for contributors?
- Documentation
- Discoverable documentation in repository files and or links from in repo files to wiki
- More documentation and make it discoverable directly from the repository. So that as soon as you find the repository, the documentation stands out.
- More useful Gerrit front page - more guidance, what does it mean, what are the processes, how can i find XYZ
- Improve documentation on how to contribute via Gerrit. Especially for folks coming from Github - using contributing information in repos.
- Video introductions on how to contribute.
- "New contributor" bot tells folks what to read to make a "good" contribution
- We have this. Maybe it should Remind them of documentation, what to expect next. ( Clippy for Phabricator/Gerrit ;-) )
- Move everything to GitHub ;-) ( because they already seem to do some of the things mentioned )
- Maybe tounge-in-cheek, maybe not. Contributors.md (bullet list templates for issues) and other features that help with new folks.
- Discoverable documentation in repository files and or links from in repo files to wiki
- Interactivity
- Custom message from git-review on submit if you are "new" to repo / project
- A custom message that tells you what to do in your terminal next. Discoverability of the rules
- Custom message from git-review on submit if you are "new" to repo / project
- Metrics
- Making discovery the level of activity and the current key contributors ... like Github (again ^^') (activity graph and/or activity ranking of projects)
- Documentation
- Summary, conclusions and follow ups
- Go small steps but know what steps and why because the gap from starting somewhere to getting to somewhere useful seems so large now.
- Motivate volunteers and contributers
- Highlight / advertise contributions made from beginning volunteers / others. For example write on tech news, post on Twitter, write on user's talk page
- Lack of volunteers contributions might come from lack of recognition
- https://dri.es/balancing-makers-and-takers-to-scale-and-sustain-open-source
- Getting more visibility is something Tech Relations is working on> more data, blog posts. There's a misconception around volunteer activity
- Timo writes the production excellence blog post, highlighting contributions.
- Wikimedia Tech Twitter now owned by Sarah R.
Impressions:
- attendees seem happy overall.
- a few praises about the session.