Decision-log of RCM/RPM for documentation

[aleesteele]

@AlexandraAAJ and myself will be using this issue for logging decisions and questions that come up while doing community management and project management-related tasks. This may have to do with the repository splitting (#3352) or the organisation (#3213), or it may have to do with supporting working groups (#2729), organising events or writing newsletters.

This may be done informally here, but will help with the creation of more official documentation related to working group organisation and decision making (#3499 ).

[aleesteele]

Decisions related to newsletter writing (flagging for @the-turing-way/infrastructure folks!):

• Should all issues be moved over to the new repository?
• Should new issues related to newsletters all be made on the new repository including the call for 'contributions'? (People tend to comment on issue with things they would like to promote)
• Where should questions related to newsletters on a community management or project management level be made?
• Who transfers all the issues?

General:

• All the README.me files for all the repositories should have a description

[aleesteele]

Planning & Promoting events:

• How should we share this backend planning document? https://docs.google.com/spreadsheets/d/1lWCWKAAXSlluo5d78LAjoMS9dfDxB27Y7Fb_wGI9B6Q/edit#gid=577525947 - Should it be shared? (It is very overwhelming?
• How should we share this event pad list more openly so that others can contribute? https://annuel2.framapad.org/p/ttw-event-calendar-2024
• Can we link to this pad in the README for both members and the public?
• Should all events be logged in a new repository? In the planning, in progress, and completed stages?
• How does this affect how people interact with the planning process?

[sgibson91]

(I'm phrasing these responses as questions because tbh, unless you're asking the infrastructure folks to specifically do something, or build a tool to do something, I'll be fine with whatever you decide.)

• Should all issues be moved over to the new repository?

(I'm taking this to mean all newsletter-specific issues) I don't see why not?

• Should new issues related to newsletters all be made on the new repository including the call for 'contributions'? (People tend to comment on issue with things they would like to promote)

Yes, I think so?

• Where should questions related to newsletters on a community management or project management level be made?

Maybe we want to have GitHub organisation-level Discussions for conversations that either (i) don't fit to any specific repo, or (ii) span the topics of multiple repos? https://docs.github.com/en/organizations/managing-organization-settings/enabling-or-disabling-github-discussions-for-an-organization (it would mean having a specific repo to host them, which we would need to delegate or create a new one, such as discussions)

• Who transfers all the issues?

Unless you want the infrastructure WG to write a script to automate it (very reliant on the relevant issues being uncovered through GitHub search and not needing to be gone through by hand), I'd say anyone who has the appropriate permissions?

[AlexandraAAJ]

Thanks @sgibson91, is it possible to automatically open up a new issue the first day of the month with the "Month XX Newsletter" (we would create a script to encourage contributions) and an alert to other repos to contribute?

[sgibson91]

is it possible to automatically open up a new issue the first day of the month with the "Month XX Newsletter"

Yes, actually @Arielle-Bennett has an example of this

and an alert to other repos to contribute?

This I'm less sure about - could probably be done, but it'd need to be thought through

[Arielle-Bennett]

@AlexandraAAJ happy to walk you through this ( although most of the credit goes to @sgibson91 & @JimMadge who have helped with trouble shooting my poor understanding of GitHub actions :D )

[JimMadge]

That sounds totally possible with actions. @Arielle-Bennett I think I fixed the errors (that I also introduced 😅) in your example but I'm not sure if that has been tested.

I'm sure what is there could be easily adapted to a monthly newsletter template.

[AlexandraAAJ]

Thanks @JimMadge, would you be available during Thursday's coffee chat (14:30) to show me how to run this? Other people might be interested to join and learn as well :)

[JimMadge]

@AlexandraAAJ Absolutely 👍.

[aleesteele]

Currently developing/thinking through the decision-making process for choosing a URL for the community, and how to make this an inclusive process for the community.

Drawing upon consensus in large groups from the Citizens handbook, specifically from this part of the text:

1. Someone makes a proposal for a certain course of action
2. The facilitator asks for clarifying questions to make sure everyone understands
   precisely what is being proposed
3. The facilitator asks for concerns
   a. During the discussion those with concerns may suggest friendly amendments to
   the proposal to address the concern, which the person originally bringing the
   proposal may or may not adopt
   b. There may or may not be a temperature check about the proposal, an
   amendment, or the seriousness of a concern
   c. In the course of this the proposal might be scotched, reformulated, combined with
   other proposals, broken into pieces, or tabled for later discussion.
4. The facilitator checks for consensus by:
   a. Asking if there are any stand-­‐asides. By standing aside one is saying “I don’t like
   this idea, and wouldn’t take part in the action, but I’m not willing to stop others
   from doing so.” It is always important to allow all those who stand aside to have a
   chance to explain why they are doing so.
   b. Asking if there are any blocks. A block is nota “no” vote. It is much more like a
   veto. Perhaps the best way to think of it is that it allows anyone in the group to
   temporarily don the robes of a Supreme Court justice and strike down a piece of
   legislation they consider unconstitutional; or, in this case, in violation of the
   fundamental principles of unity or purpose of being of the group.*
   There are various ways of dealing with a block. The easiest is simply to drop the
   proposal. The facilitator might encourage the blocker to meet up with those who
   brought the proposal, to join the relevant working group for instance, and see if they
   can come up with some kind of reasonable compromise.

Questions:

• How to get input on community infrastructure decisions in inclusive way?
• How long should timeline be for voting?
• Who should break a tie (if votes contradict proposal)? What is the process for that?
• Who should present the proposal?
• Where should the proposal be presented for community input?

Made a proposal in #3266 to test out for now.

[aleesteele]

As I write #3533 - a few decisions are coming up as I go into the archive of the past few years of the project:

• Proposing/creating/archiving slack channels: [Phase 0] Digital Gardening: Community Events & Communication Review #2644 (reply in thread)
• Creating/ending community platforms
• Decision-making on platform auditing (what to end and what to start)

[aleesteele]

Adding the evaluating tables here from #3509

Tied to questions of how & who decides when we move to new platforms, and how to publicly build evidence to do so in an open, transparent, and equitable way

Platform options table

Platform	Migration burden	Financial model	Open source	DP terms okay?	Notes	Decision (Y/N)

Needs analysis

Need	How it currently works with XXX	How XXX would change this	Recommendation

[aleesteele]

Adding the comms template as it is currently being discussed/deployed at #3266 and #3213

Communication Activity	Target Audience	Who is involved & role	Timeline	Notes	Status

[aleesteele]

Going to very beginning of the project: https://docs.google.com/presentation/d/1HcKjeikxAAfKDCb5Okh1EqPbabedM3c7xIVuKv1Cqeg/edit#slide=id.g13b346a17cb_0_535

Hi everyone! 👋I wish I could join you at your meeting today, but alas. I’ll be in a course called Solidarity Infrastructures at the School for Poetic Computation - which might be interesting for folks here. Hope to join you another time. If you have any questions or would like to chat, feel free to reach out to me at asteele@turing.ac.uk :) or on the TTW slack (linked on the page).

I thought I’d tell you a little bit about how I went about forming working groups with The Turing Way project. I joined the project in March 2022, and spent the first 6 months learning more about the project which you can read more about. This culminated in realising that there were identifiable workstreams within the project that could be formalised into ‘working groups’ to help field support and agency in the growing project (and prevent the theory of structurelessness), taking cues from the models of other open source communities (and other forms of social organisation). This research into governance was pretty informal (like this slide deck of research), and also formaled (like when we participated in the Open Life Science programme)... And it’s been a bumpy road, but a huge learning experience!

The following 6 months (Sept 2022 - March 2023) were spent working on supporting the trialing of 4 working groups: Trainers & Mentors, Reviewers & Editors, Infrastructure, and Accessibility. We also formalised a working group for Translation and Localisation, a sub-community that had formed organically in the previous two years. For groups meeting for the first time, we helped to set up their meeting infrastructure: aims, project ideas, meeting notes, and other bits and bobs. At times we gave over the reins too early (and they felt they had no support or guidance for their work), and with others, we’ve held on to the reins perhaps a bit too tightly. Looking back on that time, it became clear that this is what moving at the speed of trust looks like, to quote adrienne marie brown.

From March 2023 to September 2023, I started preparing documentation needed to help with this formalisation in a templatable way for other similar groups to form working groups (you can see a PR I finally made with some of this info here!), and we also moved into a github organisation (from a repository), which has allowed different groups to have their own spaces/repositories. This has helped with increased autonomy and increased decentralisation of the project.

From September to December 2023, we were conceptualising and planning the Book Dash, our biannual contribution event. This was a testing ground for another working group, this time oriented around a community event (like a planning committee!). We invited different community members and used this space to trial learnings from the first two working groups, with more support for meeting infrastructure.

In January 2024: there’s a bunch of documentation and learnings to share about the whole process. Narrating it like this - it seems like we were always going to be like this, but that was definitely not the case! Hope that helps with your discussion ☺️

[aleesteele]

Review process for community policy (discussing the accessibility policy -> #3581

Key questions emerging from this process (thanks to the RCM team, as this was brought to our collective team meeting!)

• How can collective peer review happen within the commmunity?
• Who is responsible for signing off at the document?
• Can the review and discussions be had in public or in concentrated spaces? (i.e. Book Dash, Collaboration Cafe, )
• What spaces does that peer review happen in? On the issue? In other places or spaces?
• How do we ensure that folks have the psychological safety need to discuss these kinds of policies and practices?

[aleesteele]

Questions from the onboarding call

• How do we give persmissions to the repository where the CM or other people with admin rights are present?
• What's the process of adding people to the repository more broadly?

[aleesteele]

@AoifeHughes - tagging you here so we can log some of the decisions & questions that come up in our 1:1's and as you explore the repository and learn more about the project! This might be a great place to log things related to book dash too.