New workflow proposal for Language workstream #114
Replies: 1 comment 4 replies
-
|
This is a good proposal and the workflow makes sense, and I'm going to walk through it to ask some questions or considerations. I'm looking to make sure our assumptions are largely aligned and clear to people who aren't immersed in this. So some of these comments may be useful to consider for the documentation around this workflow — setting context, etc.
For the docs some additional language (and @LarryKunz please check my assumptions here): "This new workflow for considering terms for the wordlists intends to take advantage of one of the strengths of Open Source: a transparent and asynchronous workflow that lets people work across timezones to get work done more efficiently and quickly. The community continues to have monthly sync meetings, which is a good opportunity for new contributors to meet many others. Although we may discuss various terms under consideration in that meeting, we are deliberately pushing the decision making process into this new workflow. This massively increases the number of potential participants in a word discussion. When doing the work of considering a term, the people who volunteer to work on that term may choose to have one or several meetings in real time to talk through difficult topics. The results of these meetings then go back into the workflow, perhaps with some points anonymized or generalized from the meeting."
Extrapolating out the steps in the workflow, I see how you are viewing those environments and contributor type. I think it would also be useful to have this workflow include a few role definitions and assumptions about them, e.g,: Person with a term they want INI to consider for a wordlist
Contributor who works on terms for the wordlist
Maintainers who can lead discussions to conclusions and commit changes
I don't disagree that GH discussions can work for this purpose and it's certainly easier than a chat UX. I think it needs to be clarified that the Discussion is intended to be the formal and transparent record of discussion about the term. We need to identify there is a separate place for the async central discussions where the whole contributor and watcher community can see new terms are being discussed, be invited to participate, and hear about the status of terms going through the workflow (so they aren't a surprise.)
What I think is missing is how we track that there is a term and then assign it? Is the discussion thread intended to be the place for tracking and assignment? Does that work in any way similar to Issues? Ideally, the first step of intake of a new term is the creation of a tracking Issue in the project's main issue tracker, GitHub. But perhaps that's what you have in mind, just that the way a term comes to light and is accepted for intake is via a discussion thread? If that's the case, then I think the issue creation from Step 4 needs to go back to the last part of Step 1 — the gatekeepers who decide if a term is discussed or not, they need to create an Issue to track that discussion and decision. E.g., if they decline to include a term, it's recorded in the same location as terms that are accepted for work. This also lets a term do intake if e.g. a maintainer hears a new term and wants to have it worked on, they can skip the intake discussion and file an issue to put it in front of everyone post haste.
My recommendation is we do everything possible to make it possible for 100% of the word discussion contributors are able to make at least one pull request of a term. It's okay that it's not a hard requirement, we want to bring people along gently rather than yank on them. But I think we should work to rotate the PR creation through all the active contributors and maintainers as much as possible. The reasoning is to capture in the record the depth and breadth of organizational participation in the wordlists. It is also one of the best ways we have right now to track the participation and provide credit to community members.
+1
Bouncing these thoughts over to @LarryKunz , thanks! |
Beta Was this translation helpful? Give feedback.
-
|
@LarryKunz Checking in here, have you had the chance to review this discussion? |
Beta Was this translation helpful? Give feedback.
-
|
Hi @quaid, I am moving this forward. Here is a revised plan based on the points you shared. WorkflowSuggesting a term for evaluationTo lower barrier to submission of new terms for consideration, we will use Google Forms. Anyone can submit a term for consideration, once the form is submitted an issue is created in inclusivenaming/org for documentation and to serve as a single source of truth for tracking a term's journey through evaluation. Review ProcessA suggested term is shared with reviewers (More on this later) to vote for evaluation via a dedicated email list and once their is at least 3 responses, a google doc is created for collaborative review of the term's submission along with a draft of its listing information. A review should be completed in at most a month after submission. Reviewers can use the weekly Community office hours, which I have scheduled for thursdays to collaborate or adhoc meetings can be scheduled as needed for synchronous collaboration. ApprovalOnce all the reviews are done and at the end of every month, an email is sent to reviewers to vote on the approval of a term for inclusion in the wordlist. PublicationAt the end of a quarter, all the approved terms are published in a quarterly release, managed by maintainers (More on this later). CollaboratorsTo increase participation in the community, a call for participation will be sent to the general mailing list inviting people to express interest in becoming a reviewer or/and maintainer. A reviewer helps to review suggested terms according to the Language Evaluation framework and votes if a term is approved for consideration and approval, after review. A Maintainer helps to create issues and Pull requests for addition of a term to the wordlist. An individual can be both. Next Steps
Let me know your thoughts, I will be moving forward with the next steps from Monday, August 4 cc: @Favourwilliams |
Beta Was this translation helpful? Give feedback.
-
|
This is more clear, compared to the initial flow term proposal, makes its easier to implement and drive engagement within the community |
Beta Was this translation helpful? Give feedback.
-
|
Looking at the issue list, we can test this new flow with a term yet to be attended to, to ascertain clarity of this new flow |
Beta Was this translation helpful? Give feedback.
-
The Inclusive Naming Initiative is switching to a more asynchronous organization where activities can happen without haven to wait for meetings. The Language workstream is the core of the initiative, thus streamlining its processes and making it for collaboration to happen is crucial.
The goal of this proposal is to make it easier for new term recommendations to be proposed and enabling collaboration in an environment that most contributors are used to.
Flow
Step 1: New Term proposal created a a Discussion in the GitHub Language workstream discussion category. From here, the Language workstream leads, review the proposal and decide on next steps.
Step 2: A Google Doc is created in the Wordlist Google Drive folder and all the collaborators for the term are invited to the document. The folder is public by default with the commenter permission.
Step 3: The Language workstream leads iterate through the review of the term and after its complete, the Community Lead is assigned to it.
Step 4: The Community lead creates an issue on the website project (or a dedicated wordlist project in the future) for adding the new term and proceeds to create the pull request to add the term to the wordlist with the Language workstream leads as reviewers.
To promote collaboration, the discussions for new terms and progress will be shared in bi-weekly emails to the community.
What do you think @LarryKunz @quaid ?
Beta Was this translation helpful? Give feedback.
All reactions