Great topic!

There are a number of related (draft) movement strategy recommendations:

• decentralizing development of the platform
• participatory planning (more about product than platform, not sure platform was meant here in the "things the Technology department owns" sense though)
• technology vision and strategy

Good open source citizenship, relationships with other open projects (esp. upstreams and downstreams) and better promotion and evangelism of our software are also good topics for discussion.

(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.

In T234657#5571386, @Tgr wrote:

Great topic!

There are a number of related (draft) movement strategy recommendations:

I think these should be added to pre-reading section. As of now it seems a bit hard to prepare (think beforehand) for useful questions/suggestions on this topic (which can be have a huge impact on our ecosystem) based on the description alone.

@Bmueller @greg it might also make sense to share some of the most recent challenges that we discussed which prompted this session. It might add context to the problems we are trying to solve.

picture captures of sticky notes from the session:

Slides: https://commons.wikimedia.org/wiki/File:Platform_Stewardship_-_Wikimedia_Technical_Conference_2019.pdf

Wikimedia Technical Conference
Atlanta, GA USA
November 12 - 15, 2019

Session Name / Topic
Platform Stewardship
Session Leader: Birgit + Greg; Facilitator: Brooke; Scribe: Nick

Session Attendees
Alexandros, Lars, Greg, Birgit, Will, JR,

Notes:

• What we are trying to explore is how can we live up to the ideals we have as an open project?
  • We want to be diverse
  • We want to complete our targeted projct
• OSS doesn't mean anything is possible, we need to have process and we need to have process that work with a diverse group of individuals
• The platform we are discussing here is the entire tech stack
• Stewardship should be the process of guiding and supporting communities
• There is a huge lack of clarity of which contributions are critical, wanted and which don't work
  • How can projects be supported long term?
  • There is a wrong assumption that wmf takes over ownership and maintenance
• What are the concrete questions and problems?
  • How do we support and enable non-staff contirbutions & ownership
    • How do we enable them to be sustainable and effective as something we and the community can rely upon
    • Focus is on non-staff but how can this apply to all contributions? For example, experiement from a product team internally also needs to have thinking about long term support and maintenance
  • What are the conditions and requirements needed?
• Breakout groups
  • Review the existing process we have [now]{.underline}
    • What works well now?
    • What doesn't work well now?

Breakout 1

• - Group notes general themes
  • Code reviews
    • Why does this not work well? Is it resources? Or interest?
  • Merging
    • Contributions from community not reviewed and not merged
    • Where is the clairty around why or how?
    • Who is the benevolent dictator saying yes or no?
  • Sun setting
    • Beta features
      • Just sit there
  • Sometimes we find stewards, sometimes the process works
    • Sometimes hard time thinking positively, more often than not
    • Acknowledging we have a problem and we're working through it
    • It's normal that thinks get orphaned
      • That no one is taking care of something major, should be handed off or killed off
      • There is a long time before thinks are picked up
  • Should code stewardship happen more?
    • It should happen right when someone leaves
  • Stuff that shows up that is technically sound
    • But how far has it been evaluated?
  • Beta features works well
    • Reviewed, undeploy date
    • Reflected on what needs to happen next
    • Gate, is it well gated or not?
  • +2 policy
    • Process of getting +2, kind of works but has some messiness
    • Handling the exception case is hard
      • Establish a habit of committing good code
      • Then others vote, maintainers can give it
      • There are ways you can escalate all the way to the CTo
      • Is announced on the mailing list
  • Sunsetting is hard
  • Dev maintainers list is out of date
    • Manual to update
  • How do you get +2 when there is no maintainer?
    • You have to go to techcom
    • Tim committed to regularly looking at the requests
  • Can direct questions to the lack of code maintainer ticket?
    • Loop
  • RfCs slow
  • SPOFS

• Report Back Group 1
  • Merge paralysis
    • Looking into what others do
  • +2 policy not working well
    • Who is responsible? Who is responsible?
  • Beta features work well
    • Constraints are known, requirements are known
    • Gated well?
  • RfCs
    • No consistent way to do RfCs
    • Somtimes done, sometimes not

• Report Back Group 2
  • RfCs slow
    • Complicated and therefore out of reach for volunteers
  • Maintainers page
    • Out of date
      • Does not get updated even when it should
    • Manual
    • Should think about ways of pulling this information automatically
    • Clear that there are a lot of SPOFS
  • SPOFS
  • Sunsetting is hard
    • Even with the decision, getting the time and resources to make it happen is hard, not highly prioritised
  • About >50% of the time we find stewards
  • +2 policy
    • Works well for big teams
    • Process kind of works
    • May be doesn't work for 3rd party extensions that the foundation doesn't use

Breakout 2

• - What doesn't work...how can we fix it?
  • What's missing?

• Group notes general themes
  • Code stewardship, how do we make it less slow/heavy?
    • Why is it slow?
      • The really difficult reviews are legitimately difficult, for example, graphoid
      • Review process is slow
      • Once we review and we decide to sunset, it's not trivial
        • We should have a better sense/process of how to remove something from production
        • How do we implement that in planning in the future?
          • Anything that goes to production should come with such a plan?
      • Easier process to get data on projects that are around
    • Offboarding checklist
    • Record of origin
      • Author etc
      • URL for sunsetting plan
  • RfC process
    • Doesn't feel onerous as a process
    • Review whether it is an RfC
    • Cheat and go to IRC meeting to get through
      • For a community member this isn't an option
      • Social/context problem
    • Live RfC
    • Anyone who wants to discuss this should be able to answer 3 simple questions, supplied by the author per RfC
    • Can we have more detail on when you need to do the RfC process
  • CR
    • If you make a PR on github, you can very easily see who can review and merge
      • We don't have this
      • Suggested reviewers
        • How can this be sorted?
          • Gerrit has a plugin that looks at stats on relevant people
            • It doesn't display them, it just adds them
              • Would require us to make that change upstream
  • +2
    • Finding who the +2ers are shouldn't be hard, it should be inherrent
    • What are other projects governance rules for this kind of work?

• Group 1 report back
  • Abandone all hope
  • Code Stewardship request
    • Heavy process
    • Better discoverability of data about projects
    • While it feels slow, the slowness is created by really difficult cases which is bound to planning and finding the resources
    • No process for sunsetting if that is the outcome of code stewardship
    • ACTION: If we need a process of being sunsetted if that's the decision.
    • ACTION: Better discoverability of data for the rubric.
  • RfC
    • Inaccessible to new comers
    • Who do you talk to if a dev says no or yes?
    • ACTION: Figure out a way to make it more clear for newcomers that an RFC is required.
  • +2
    • How do you solve this slowness
      • Lack of responsibility
      • Can we find one more layer of people?
        • Currently Tim
      • Lazy consensus
        • Patch is sliently accepted if no one objects
    • ACTION: adding a layer of people to do review of new additions on various repos
    • ACTION: look into what other companies do wrt code review and maybe look into lazy concensus.
• Group 2 report back
  • RfC
    • Author has a list of questions they supply so that people know what is going on, to add additional questions
    • Techcom have standard questions or questions for the author in advance
    • There is a high cost to context sharing
    • ACTION: Dan A. propose the "popquiz" approach to TechCom
  • Dev/Maintainers
    • Out of date and manual
      • Making sure there is a check point on offboarding to make sure it is updated
      • Regular reviews
        • Clone JR
        • Manual way to ensure it's up to date
      • Wiki page of all the info is great but separate from where people are
        • maintainers.yaml inside the project, keep the information close
          • Author
          • Sunsetting plan
    • ACTION: Greg delegate creation of a proposal for the maintainers.yaml idea (can be merged with other metadata files, if possible)
    • ACTION: JR delegate/make a proposal for reviewing WMF offboarding docs for integration with Dev/Maintainers (or maintainers.yaml)
  • SPOFS
    • Gerrit, trying to find reviewers for patches
      • Suggested reviewers plugin in gerrit
        • Will add people who have recently touched this file/code
          • Unfortunately, auto adds but we should create an upstream fix to simply display the list of people to go bug to get help
    • Gerrit reviewer bot that you can opt into
    • ACTION: Tyler do/delegate the creation of a contract proposal for modifying the Suggested Reviewers to only display potential reviewers instead of adding them as reviewers

General instructions
This sheet is for scribes and participants to capture the general
discussion of sessions.

1. Note-taker should go for a more 'pure transcription' mode of documentation
   1. Don't try to distill a summary of the core details unless you're confident in your speed.
2. All note-takers should try to work in pairs and pass the lead-role back-and-forth when each speaker changes.. Help to fill in the gaps the other note taker might miss.
   1. When you are the active note-taker in a pair, please write "???" when you missed something in the notes document.
   2. If a session only has one note taker present, feel free to tag a session participant to help take notes and fill in the gaps.
3. In your notes, please try to highlight the important points (that are usually unspoken):
   1. INFO
   2. ACTION
   3. QUESTION
4. It's also good to remind session leaders, facilitators and participants to call out these important points, to aid in note taking.
5. Sessions might have activities that will result in drawings, diagrams, clustered post it notes, etc
   1. Please tag a session participant to capture these items with a photo and add them to the Phabricator ticket.
6. Some sessions might have breakout groups which means that there will be simultaneous discussions.
   1. Session leaders should direct each group to appoint a scribe to take notes (in this document).
7. At the end of each day, notes and action items will need to be added into the related Phabricator ticket (workboard: ) for each session
   1. This can be done by any and all conference attendees.
8. Additional information about note taking and session facilitation:

Summary of ACTION items:

Code Stewardship Reviews

• ACTION: If we need a process of being sunsetted if that's the decision.
• ACTION: Better discoverability of data for the rubric.
• ACTION: Figure out a way to make it more clear for newcomers that an RFC is required.

+2 rights

• ACTION: adding a layer of people to do review of new additions on various repos
• ACTION: look into what other companies do wrt code review and maybe look into lazy concensus.

RFC

• ACTION: Dan A. propose the "popquiz" approach to TechCom

Dev/Maintainers

• ACTION: Greg delegate creation of a proposal for the maintainers.yaml idea (can be merged with other metadata files, if possible)
• ACTION: JR delegate/make a proposal for reviewing WMF offboarding docs for integration with Dev/Maintainers (or maintainers.yaml)
• ACTION: Tyler do/delegate the creation of a contract proposal for modifying the Suggested Reviewers to only display potential reviewers instead of adding them as reviewers