Page MenuHomePhabricator

Wikimedia Technical Conference 2019 Session: Integrating contributions from other teams or volunteers
Closed, ResolvedPublic

Description

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:

How to improve the workflow around contributions?
( 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:

How to create responsibilities for code and projects?
( 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:

How to give good guidance for contributors?
( 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


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:
    • 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?
  • 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
    • 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)
    • 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 )
  • 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.
    • 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
    • Metrics
      • Making discovery the level of activity and the current key contributors ... like Github (again ^^') (activity graph and/or activity ranking of projects)
  • Summary, conclusions and follow ups

Impressions:

  • attendees seem happy overall.
  • a few praises about the session.

Event Timeline

debt created this task.Oct 4 2019, 3:50 PM
TK-999 awarded a token.Oct 5 2019, 2:55 PM
hashar awarded a token.Oct 7 2019, 2:46 PM
hashar added a subscriber: hashar.Oct 7 2019, 2:48 PM

My biggest challenges are:

  • find whom actually maintains the code I touch and how to get them interested in reviewing and accepting my proposal.
  • on the opposite for some of the code I maintain, I have trouble finding co maintainers and for at least one repo, trouble to catch up with all the changes being proposed.

Hey @hashar would you be interested in leading this session? - you could also co-lead it with @WMDE-Fisch, who has some experience in this area too (he might be still out of office, I guess @WMDE-leszek knows more) - I think you would be great as a session-(co-)leader for this :-)

TheDJ added a subscriber: TheDJ.Oct 12 2019, 3:14 PM

Maybe we can discuss about an incentive system to review code. I feel with the current setup of teams it is very hard to incentivize anyone to review code outside of their own responsibility. It's basically a favor that people are doing to eachother and while nice at the human level (and that will probably always be the primary motivator to use), maybe there is more we can do to encourage people to reach across team/volunteer/3rd party lines..

gamify ? 😂

Tgr added a subscriber: Tgr.Oct 13 2019, 9:34 PM

Isn't this sort of the same as T234660: Wikimedia Technical Conference 2019 Session: Code Health/Code Review?

I agree with @TheDJ that lack of incentives or responsibilities is one of the main problems here.

I agree with @TheDJ that lack of incentives or responsibilities is one of the main problems here.

I agree.

Also among the large general Gerrit backlog and also the freedoms that an open Gerrit brings I find it quite hard to actually determine what I should review and what people want me to review.
Currently that is easy within a team that has day to day communication, and also across some teams that work with each other day to day, but perhaps this communication could be formalized in a layer on top of just adding reviewers to a patch? Some sort of priority for things to review would be quite nice too.

Hey @hashar would you be interested in leading this session? - you could also co-lead it with @WMDE-Fisch, who has some experience in this area too (he might be still out of office, I guess @WMDE-leszek knows more) - I think you would be great as a session-(co-)leader for this :-)

Yes I am willing to co-lead.

I can definitely present tip and tricks to ease integration of contributions, specially on the code review side/Gerrit. For features/code and how different people synchronize outside of a team scope, I can not tell, the way I work is probably not an example to follow since it is barely formalized and I have lot to improve myself :-D

Maybe we can have the session driven by some examples to raise awareness of what is successfull/bad for various teams/people. Then eventually break out in small groups and come up with a set of good/bad and recommendations.

There is indeed a lot of overlap with T234662: Wikimedia Technical Conference 2019 Session: Integrating contributions from other teams or volunteers as pointed out by @Tgr , though I see that other session to focus on code health automatic feedback. This session could focus on the people behavior and incentives to help folks to work together.

Poking again @WMDE-Fisch lets sync up whenever you are back around :]

Tgr added a comment.Oct 16 2019, 12:56 PM

Also among the large general Gerrit backlog and also the freedoms that an open Gerrit brings I find it quite hard to actually determine what I should review and what people want me to review.

Yeah, it's hard to differentiate between "this might be interesting for you" and "could you review this please?" (plus some of the change tracking we use involves people being automatically added as reviewers, which makes it impossible to send them a signal by manually adding them). It's probably just a matter of developing new community norms (like adding people to CC instead of reviewers) - as such, definitely a good topic for discussion.

Yes I am willing to co-lead.

Maybe we can have the session driven by some examples to raise awareness of what is successfull/bad for various teams/people. Then eventually break out in small groups and come up with a set of good/bad and recommendations.
I can definitely present tip and tricks to ease integration of contributions, specially on the code review side/Gerrit. For features/code and how different people synchronize outside of a team scope, I can not tell, the way I work is probably not an example to follow since it is barely formalized and I have lot to improve myself :-D
This session could focus on the people behavior and incentives to help folks to work together.

@hashar awesome, thanks :-) - I like that idea. That would provide the room to exchange on what worked/didn't work in the past and come up with a list of recommendations for better/best practices.

In case Fisch is not back in time - would anyone in this round be interested in co-leading this session?

@hashar, looks like Fisch will be back in time, will add both of you as session leaders to the task description. :-)

Bmueller reassigned this task from Bmueller to hashar.Oct 17 2019, 7:33 PM
Bmueller updated the task description. (Show Details)

@WMDE-Fisch reached out to me. I have skip on Monday and this Tuesday I am helping on some post Gerrit migration issue. Timing is hard :-\

debt triaged this task as Medium priority.Oct 22 2019, 7:10 PM
greg added a comment.Oct 23 2019, 9:40 PM

(Programming note)

This session was accepted and will be scheduled.

Notes to the session leader

  • Please continue to scope this session and post the session's goals and main questions into the task description.
    • If your topic is too big for one session, work with your Program Committee contact to break it down even further.
    • Session descriptions need to be completely finalized by November 1, 2019.
  • Please build your session collaboratively!
    • You should consider breakout groups with report-backs, using posters / post-its to visualize thoughts and themes, or any other collaborative meeting method you like.
    • If you need to have any large group discussions they must be planned out, specific, and focused.
    • A brief summary of your session format will need to go in the associated Phabricator task.
    • Some ideas from the old WMF Team Practices Group.
  • If you have any pre-session suggested reading or any specific ideas that you would like your attendees to think about in advance of your session, please state that explicitly in your session’s task.
    • Please put this at the top of your Phabricator task under the label “Pre-reading for all Participants.”

Notes to those interested in attending this session

(or those wanting to engage before the event because they are not attending)

  • If the session leader is asking for feedback, please engage!
  • Please do any pre-session reading that the leader would like you to do.

I don't think so, at least not on every regard. I would say that T234660 is really mainly about Code Health and the mechanics/processes behind that. This obviously also includes "manual" code review somewhat ( what I would say that this session is a lot about ) - but I would see T234660 more focusing on the rules, concepts and CI mechanics for good code health and the communication around these three aspects.

WMDE-Fisch added a comment.EditedOct 25 2019, 1:23 PM

For this session I see roughly the following areas that could be addressed. We might want to focus on some of these beforehand or try to figure that out during the session. Also it might be, that some other session is covering some of this. I have not checked everything there yet ( and probably the other sessions will also begin to from more over the next days )

Kinds of contribution e.g.:

  • Code
  • Bug reports
  • Feature requests
  • General comments and feedback

Channels of contribution ( and responsibilities for those ) e.g.:

  • Gerrit / Github
  • Phabricator
  • OnWiki

Code areas of contribution ( and responsibilities for those ) e.g.:

  • Extensions
  • Areas in core
  • Features
  • Gadgets / Tools
  • Infrastructure / Operations

Mechanics and workflows to help address contributions e.g.:

  • Bug-Mastering
  • CI tests & validations
  • Adding reviewers automatically
  • Gerrit office hours
  • Regular sync meetings

Appropriation of contributions

Any additions or objections so far? :-)

hashar reassigned this task from hashar to WMDE-Fisch.Oct 25 2019, 1:54 PM

Sounds good yes!

From the quick conversation we had, sounds like we want to define a limited scope we might not have enough time in the session to properly focus.

We might want to define a clear goal statement for this session, something like improve code collaboration.

It seems the session might benefit from listening from each other experiences and gather ideas. Potentially some quick brainstorming to explore potential new ideas. We might able to prepare one or two problem statement to work on to kick start hose discussions.

A good outcome would be a set of ideas worth trying and/or a set of recommendations. It would be great to form an informal working group which could then follow up on actions.

Per discussion with Christoph, I am reassigning the session to WMDE-Fisch, but I am definitely co-leading :-]

I extended my comment above to show examples for the different aspects of contributions I identified in this first exploration.

I think the session should probably focus on contribution of code and while discussing that we will probably touch the aspects of the other topic areas I mention. ( this might have been obvious to some of us, but I think "contribution" is really broad )

WMDE-Fisch added a comment.EditedOct 29 2019, 3:59 PM

In the spirit of transparency and participation, here's the next step to further define the session. I gathered some "key" questions that we could try to answer in the session. Again feel free to comment, extend and favor.

  • How can we make sure, that contributions are noticed by the people responsible?
  • How can we make sure, that there are people responsible for a code base / projects?
  • How can we make sure, that contributions are initially addressed? ( in some way )
    • leaving a first comment appreciate and rank / classify
    • communicate next steps
    • reviewing
  • 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? ( in some way )
    • cleanup
    • reviewing
  • How can we make sure, that there’s time to address contributions?
  • How can we make sure, that contributors know how and where to contribute (best)?
  • How can we make sure, that contributors know what to contribute? ( related to the above )
  • How can we make sure, that processes around contribution and their integration are known and transparent to contributors?

How can we make sure, that contributors know how and where to contribute (best)?

I would also add "if/what" to the list. Dealing with unwanted/surprising/unsocialized changes in Gerrit can be emotionally taxing. For bigger changes there should be a task first to discuss the issue and implementation directions. I guess this overlaps with the last question, though.

How can we make sure, that there’s time to address contributions?

Like feature requests in Phabricator, it's probably unreasonable to think all contributions will be addressed. Could discuss the best practices how to let those contributors know if their patch isn't gonna get reviewed anytime soon, and how to avoid that happening in the future, as well as a framework for deciding what to spend time on and what not.

Thanks for the feedback.

How can we make sure, that contributors know how and where to contribute (best)?

I would also add "if/what" to the list. Dealing with unwanted/surprising/unsocialized changes in Gerrit can be emotionally taxing. For bigger changes there should be a task first to discuss the issue and implementation directions. I guess this overlaps with the last question, though.

Yes, very good point. If contributors know what to contribute it probably also increases the chances that it gets integrated. :-) - I'll add it to the list in that comment.

How can we make sure, that there’s time to address contributions?

Like feature requests in Phabricator, it's probably unreasonable to think all contributions will be addressed. Could discuss the best practices how to let those contributors know if their patch isn't gonna get reviewed anytime soon, and how to avoid that happening in the future, as well as a framework for deciding what to spend time on and what not.

Yeah, "time to address" in that regard could also just mean, we take the time to leave a comment. But even that takes time ... *sigh*

debt updated the task description. (Show Details)Nov 5 2019, 8:56 PM
WMDE-Fisch updated the task description. (Show Details)Nov 6 2019, 11:57 AM
WMDE-Fisch updated the task description. (Show Details)Nov 9 2019, 2:07 PM
Physikerwelt updated the task description. (Show Details)Nov 11 2019, 1:29 PM
Physikerwelt added a subscriber: Physikerwelt.

@WMDE-Fisch @hashar could you maybe update the ticket description and suggest an agenda?

greg updated the task description. (Show Details)Nov 11 2019, 5:17 PM
greg added a subscriber: CKoerner_WMF.
hashar updated the task description. (Show Details)Nov 12 2019, 1:53 PM
WMDE-Fisch updated the task description. (Show Details)Nov 12 2019, 1:56 PM
hashar updated the task description. (Show Details)Nov 12 2019, 2:02 PM
WMDE-Fisch updated the task description. (Show Details)Nov 12 2019, 2:17 PM
Physikerwelt updated the task description. (Show Details)Nov 12 2019, 3:02 PM
Physikerwelt updated the task description. (Show Details)Nov 12 2019, 3:15 PM
WMDE-Fisch updated the task description. (Show Details)Nov 12 2019, 6:29 PM

Just a quick short notice update for people interested. - If you find the time, you could take a quick glimpse at some of the tickets linked above that already dealt with that topic before. ( You can also do that afterwards obviously and add thoughts later.)

Quiddity updated the task description. (Show Details)Nov 12 2019, 10:56 PM

I would like to apply the "actionable items" to the Math extension. Yesterday, I cleaned up old patches in gerrit

and did a code review for active patches

Fortunately, @mobrovac reacted merged and deployed one patch which resolved T218295.

What needs to be done is to

  • (extend this list with action items I am currently not aware of)
  • thank the (first time?) contributor that resolved T218295.
  • Create a contribution.md
  • Document the contribution workflow for math (this might be complicated and deserves its own task.
  • Update the math board to have a common visual grounding
WMDE-Fisch updated the task description. (Show Details)Nov 13 2019, 2:43 PM

Following the good example of @Physikerwelt I just submitted an un-conference session where some of us could try to implement ideas generated above. Just poke me if you're interested. :-)

WMDE-Fisch updated the task description. (Show Details)Nov 13 2019, 9:41 PM

As someone watching from afar, but nonetheless interested in this session, I'd like to say thanks for the detailed notes. It's also awesome to see people already implementing some of the ideas!

https://dri.es/balancing-makers-and-takers-to-scale-and-sustain-open-source was an interesting read, as was https://github.com/adamhjk/community-compact which was discussed in the dri.es article.

Change 550986 had a related patch set uploaded (by Physikerwelt; owner: Physikerwelt):
[mediawiki/extensions/Math@master] WIP: Add CONTRIBUTING.MD

https://gerrit.wikimedia.org/r/550986

greg closed this task as Resolved.Dec 17 2019, 11:09 PM

Thanks for making this a good session at TechConf this year. Follow-up actions are recorded in a central planning spreadsheet (owned by me) and I'll begin farming them out to responsible parties in January 2020.