Formalising a TTW infrastructure working group

[aleesteele]

Summary

The aim of creating a 'maintainers working group' within The Turing Way community is to formalise the work of infrastructure maintenance within The Turing Way project.

This follows a broader push within the project to formalise roles and ways of working within the project, in line with current governance efforts. This 'infrastructure working group' operates a little differently from the others however, because the bulk of infrastructure maintenance happens through and with volunteers in the project. This means that our relationship to maintainer's volunteer labor is (and should be!) different, with structures and support explicit enough so that people can get involved as they can, while ensuring the project's continuation.

(See #2646 for more about this push to develop working groups within The Turing Way more broadly. #2035 and #2036 have more information about the governance process.)

Why should this formalisation happen?

The Turing Way relies on many open source frameworks and ways of working in order to operate, with the most obvious ties being our use of JupyterBook and Github. As a collaborative documentation project that uses open source tools to both render the guides and an open platform for collaborating to make them (content-aside), we aim to integrate support for maintainers and maintenance into the core values of the project, as we know issues of sustainability extend into the wider world of open source.

The role of maintainers in open source software projects has been extensively documented across the wider open source ecosystem, particularly focused on their importance in sustaining digital infrastructures (but alongside this: their lack of recognition or support) within teams, companies, and other related groups.

Here are a few resources and readings related to infrastructure:

• The burden of an Open Source maintainer by Jeff Geerling
• What's an Open Source Maintainer? by FOSS Life Team
• Roads & Bridges, the Unseen Labor Behind our Digital Infrastructure (Nadia Eghbal)
• The Labor of Maintaining and Scaling Free and Open-Source Software Projects (R. Stuart Geiger, Dorothy Howard, Lilly Irani)
• Working in Public: The Making and Maintenance of Open Source Software (Nadia Eghbal)

[Pending] aims of the infrastructure maintainers working group

The following aims have been developed with @sgibson91, one of the founding members of The Turing Way team, and a core infrastructure maintainer. Additional conversations have also been had with @da5nsy (with respect to ongoing 'digital caretaking' and infra management so far) and @sayantikabanik (regarding onboarding for open source projects more broadly) that have influenced the pending development of this working group.

The goals of the working group are to work on infrastructure-related tasks on both a day-to-day and longer term basis, operationalising and formalising the process that has already emerged informally with people.

• Day to day: package updates, managing bug reports
• Longer-term: managing automation requests from working groups, developing strategy for tech adoption, onboarding new infrastructure maintainers, self-directed projects
• Preparation required: developing documentation (for internal use, to be added to the Community Handbook)

Proposed Timeline

Phase 0: Kick-off meeting

• Discuss timeline + aims of WG
• Decide membership & timelines

Phase 1: Documentation of Existing Infrastructure

• Answering questions like 'Who is doing what?' and 'What do people need to know when they join?', these phase is focused on documenting existing processes to develop, update, and maintain TTW as it is currently.
• This can form the framework for something like an SRE guide for TTW maintainers (example here), including resources like a Q&A, and information about its platform building tools
• Projected Timeline: October 2022 - March 2023

Phase 2: Testing and Developing System

• This phase of the working group will be focused on developing & delegating responsibilities, with a shift away from documentation to developing processes. This phase would seek to answer questions like: 'How should responsibilities be formalised within this group for fielding infra requests or bugs' and/or 'How should other working groups interact with the infrastructure maintainers team?'
• Projected Timeline: March 2023 - August 2023

Phase 3: Expanding system & maintainers group

• This phase might combine the previous two efforts: using the documentation in order to onboard new maintainers to the project, as well as trial internal systems to field infra requests from other working groups (and internally).
• Projected Timeline: August 2023 - January 2024

Feedback requested

• Does this make sense? What is it missing? What questions to you have?
• What is included and excluded from this timeline, as is?
• How do these aims align (or not) with how you would like to work?
• How should this group communicate and collaborate? (Slack channel?)
• What support can the CM (@aleesteele) & co-leads (@malvikasharan & @KirstieJane) provide support for this group?

Who can help?

In no particular order, I'm just tagging folks here who I have observed to be a part of TTW infrastructure efforts so far (and/or have indicated interest in getting involved). Tagging is by no means an obligation to join! If you'd like to get involved, please add yourself to the thread below. 🙏

• @sgibson91
• @da5nsy
• @jcolomb
• @bsipocz
• @JimMadge
• @sayantikabanik
• @damianavila
• @arronlacey

It would also be great to tag some folks with historical/legacy knowledge of the TTW infrastructure as well – maybe a question for @malvikasharan and @sgibson91, and others? @alexmorley?

---

Updates

[sgibson91]

It would also be great to tag some folks with historical/legacy knowledge of the TTW infrastructure as well

I think Alex Morley, but I don't think he has the time to contribute any more.

[bsipocz]

I won't have time for any day-to-day involvement, but as this project is really nice and have a wonderful community, I would be happy to stay involved for bigger picture, infra PR reviews, and occasional small fixes.

[da5nsy]

I don't know them personally but to add to the list of GitHub usernames that I've seen involved in infra PRs: @martinagvilas and @timothy22000

[JimMadge]

This sounds interesting. I would be happy to be involved.

The plan sounds good to me, maybe we would want to make some changes to the infrastructure earlier on in the timeline but I think that is the kind of thing we will learn when we start the discussions.

[aleesteele]

Hi @JimMadge @da5nsy @bsipocz @sgibson91 - great!

When would be the best time to have this first kick-off meeting? There is a collaboration cafe happening tomorrow, 19 October, but that might be too short notice. How about the next one on 2 November? I can open a room there for the second hour, if that works for people. This can give more time for folks to respond as well, if joining this WG is of interest (and people have capacity, time and interest).

In the meantime, is there interest in having a maintenance-wg channel on slack as well, to get started with some asynchronous discussions? Or would you all prefer to have them here for now?

[JimMadge]

I already have some longish meetings tomorrow so would prefer to avoid that if possible.

A slack channel is a good idea 👍. In the interest of openness, perhaps we should try to make sure we use GitHub Discussions when we are talking about things that would be of interest to people outside of the group, or when we would want to invite comments/feedback.

[bsipocz]

I'm traveling until the 4th of Nov and won't have any time, so would actually prefer a little later kick off

[aleesteele]

@bsipocz @JimMadge @da5nsy @sgibson91 (adding in @arronlacey here from the Turing staff team, and @damianavila from 2i2c, who will be consulting on contributing upstream). Tagging @jcolomb, @sayantikabanik, @alexmorley in case this is of interest as well.

Hi all - great! With this in mind, I'm following up with a couple of things:

• In order to schedule a kick-off meeting, I've made a When2meet in order to learn about peoples' availability. Hopefully we'll be able to find an overlapping time to coordinate a kick-off call for most folks! Collaboration Cafes will take place on 2 November and 7 December from 15-17 GMT (in your timezone), and you are free to use that space as well. Please keep in mind that Book Dash will happening on 14-18 November, so the Collaboration Cafe that week will be canceled: https://www.when2meet.com/?17518666-ZFlSo
• I have created a slack channel, which you are free to join for real-time organising: https://theturingway.slack.com/archives/C047JKLD27K

Please let me know if you have any questions or comments about this process by reaching out on Slack or emailing me at asteele@turing.ac.uk. I want to emphasise that I know you all work on The Turing Way in your free time, and outside of other professional and personal responsibilities. We appreciate all the time you give to us, despite extremely busy schedules. We hope this is the start of being able to support your work more fully 🙏

[aleesteele]

Hiya! It looks like Friday, 2pm EST works well for many of you. I'll make an event invite ASAP, with a draft agenda (that you can feel free to edit!). 👍

[aleesteele]

Invite = Sent! I have sent out invites to @bsipocz, @da5nsy, @sgibson91, and @JimMadge for Friday, 11 November at 2pm UTC (in your timezone). If you are interested in joining this kick-off: please comment here, send me a message on Slack, or email me at asteele@turing.ac.uk!

You can find the pending agenda here, feel free to join us!: https://hackmd.io/@turingway/ttw-infra-kick-off

For all of you tagged here, we aim to leave room for asynchronous communication, and for folks to join as they can, and in which ways they can. This is all a big experiment, and will likely take some iteration... thanks so much for being here.

[aleesteele]

So concludes the first kick-off meeting of the infrastructure working group! 👍
(Some) notes are available: https://hackmd.io/_aY35tIaTpWKeYotoMcYRQ
Full transcript of meeting is here: https://hackmd.io/@turingway/Hk5Ywl2Bo

[aleesteele]

Hi folks, following up on the third core team meeting, it would be great to schedule a first meeting of 2023 in order to @sgibson91 @da5nsy @bsipocz @JimMadge @arronlacey (@gedankenstuecke - I think you indicated interest as well?)

I would love to formally introduce @AlexandraAAJ to the team (though I know she met a few or all of you at the organisational core team meeting). Following up on the meeting last week, we can follow up on how we can support you: https://www.when2meet.com/?19168871-2isRm

[AlexandraAAJ]

Dear all, following Anne's message, I will send a calendar invite today to get together tomorrow at 4 pm. Hopefully, most of you still can make it (?). Looking forward to it.

[aleesteele]

Thanks everyone for meeting #2! 😊
Notes for meeting two: https://hackmd.io/VHYQp5EASQ-VQp7yEbWTLA
Otter.ai notes: https://otter.ai/u/1JWiH1q5bbC4r8DABOJya2939OY?g=3598748&f=group&r=/group/3598748&h=Sarah,%20dannygarside,%20bgreshaketzovaras,%20sipocz.brigitta,%20jmadge,%20aaraujo.alvarez

[aleesteele]

Sharing discussion here from Slack by @malvikasharan @da5nsy @jcolomb, @sgibson91 about github permissions, notes to add to ongoing governance & decision-making discussions. Added her for posterity.

• DG: So, I think I heard MS say that our community norm was that the creator of the PR was allowed/encouraged to be the one that hits merge (after review/approval), but who has permission to do that?
  I recall inviting the PR-er to merge in the past and them telling me that it looked like they didn't have permission...
• MS: Danny, PRs can be invited as contributors with write permission then can merge it.
• DG: How does one do this? (And who can do this?)
• JC: It indeed works… just merge one PR now 🙂, the PR still needs one approved review before one can merge (I think)
• DG: Glad it works for you XX, I've had a couple of times where I've invited folks to merge and they've replied that they don't seem to have the appropriate permissions. For example:
  Fixed dead link to eScience Center language guides #2995 (comment)
• SG: Someone who has admin rights to the repo needs to invite the person as a collaborator in Settings > Collaborators & teams. So I would say we need to (these can all be lighweight processes):

1. Document who has admin rights to the repo (maybe make a team as well)
2. Make it clear that if you have admin rights, you have the power to add new collaborators to self-merge in this way, and exactly what permissions they need to do so (or some other process if we decide that is not the process we want to use)
3. Define a process for qualifying for admin rights, on-boarding and off-boarding those people as well

• MS: Here are people currently with Admin rights: https://github.com/alan-turing-institute/the-turing-way/settings/access?query=role%3Aadmin
• MS: I think all infra leads should have admin right and I have given that now to X as well. X, I agree with you about documenting the process. I think infra leads can hold the responsibility to pass admin rights to right people (such as at 1-2 leads per working group). Admin rights also comes with a risk of doing some irrevocable settings, including deleting the repo (which we expect responsible folks to know and not exploit).
• MS: My general suggestion for process is:

1. The Turing Way project leads, CM and Infrastructure leads should have the admin rights, with the responsibility to give access to other members as needed
2. 1-2 leads per working area can request to get admin rights justifying their responsibility of adding community members as contributors to the repo (with write permission)
3. Community members delivering The Turing Way GitHub workshops should have temporary access as admins as they add participants to the repo with write permission
   Anything else?

[aleesteele]

Notes from infrastructure meeting on 14/09

Attendees: Sarah (@sgibson91), Danny @da5nsy), Anne (@aleesteele)

Notes

• Re-enabling bots i.e. Alt-text bot not working #3290
• Deploy previews have to be approved by someone, now asking for approval on every PR - Re-enabling bots after organisation transfer #3289
• Speaking about need for funding (will follow up with @AlexandraAAJ -- also need help for project management for the group so far)
• Group is site-reliability focused more broadly, is the website up?
• Moving away from netlify is bigger project - need this time bought out
• ALS: Template repository for WG -> SG: Think that should be
• ALS: Splitting up the repository across the organisation, core team decisions -> SG: Shouldn't be a infrastructure team decision
• SG: "How do we do that" is a question for the core team, and the "what do we need to do that" is the infra WG
• SG: Decision quorum: confirming attendance 24hrs before the meeting is done. Decide minimum number of WG members that need to att. Asking for attendance 24hrs beforehand which affects how decisions are made.
• DG: Priorities is to enable viewing TTW in different languages
• SG: Scheduling a specific meeting around implementing this in the coming months - bringing in a friend
• ALS: Can have Book Dash project around this topic?
• DG: Yes, if we have SG's colleague able to speak with us.

Next steps

• SG: Multilingual TTW, will ask about task
• ALS/AAA: Need to build project management infrastructure for the WG (draft roadmap)
• ALS: Complete draft of Github issue for planning for next steps (
• SG: Future meeting - will reach to contacts
• DG: Book Dash - possibility of applying

[sgibson91]

• SG: "How do we do that" is a question for the core team, and the "what do we need to do that" is the infra WG

I think this is slightly misrepresented. I think "Should we do X" is a question for the core team, and "How to implement X and what do we need" is a question for the infra group

(Acknowledging that there's some information coming that'll give further clarification on what decision making powers a working group may have. So there'll be some "Should we" q's the infra team can decide on themselves.)

[sgibson91]

• ALS: Template repository for WG -> SG: Think that should be

... lead by someone who has a good knowledge of the kinds of resources a working group might need and the infra group are drafted in for implementation/automation of the template repo

[malvikasharan]

Moving comment from last year here from #3102:

Also tagging @AndreaSanchezTapia here to represent the infrastructure requirements for the translation team who work on a fork of the repo for the translators.
Their governance at the WG level will look different as described here: https://the-turing-way.netlify.app/community-handbook/translation.html -- but can be used for reference to define the following:

• Infra WG roles and responsibilities
  • Leads: who has the overview of what is happening, what is the priority
• Dependency maintainers: All-contributors bot, netlify and Jupyter Book maintainers in TTW (supporting the transition to the new version)
• Documentation building: Infrastructure documentation (such as the local deployment chapter by @arronlacey et al)
• Additional feature requests: Adding hypothes.is, Plausible (analytics), additional package -- although I think this may need to be compatible with the JupyterBook plans -- so how to make decisions for what features can be added
• Issues and suggestion facilitator: When topics like these appear, who ensures that decisions are made: Swap from Netlify to ReadTheDocs #2481 <-- this should be CM (@aleesteele) in my opinion, who facilitates RfC (via GitHub issues and newsletter) when any recommendations are made by the working group
  etc. etc.
  Each role should have a clear pathway for how decisions within the WG are made, how community members are on-boarded in the work (which work) and the feedback process.
  I assume that you all have discussed this, and have provided details either in your meeting notes or survey response. Anne will be documenting this for the infra team (and other WGs) and coordinate with you all to get your feedback -- and hope that can go on the chapter that is being documented here.