You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is part of the #15 refactoring, and is one of the solutions to help with issues and PRs going stale and giving some mechanism for maintainers to reach out beyond their direct co-maintainers for help and questions.
The Problem
Maintainers sometimes get stuck and need help with their repository, and depending on schedules and life,
they may not always be able to get (technical) help from their lesson co-maintainers.
Many times maintainers need technical help with wording or reviewing work and issues and PRs get stale because of the turnaround time for feedback.
Solution: Leverage the broader maintainer community
We understand that The Carpentries would not exist without all our volunteers.
The maintainers have different tasks and requirements than the instructors and trainers of the community.
Instead of creating rigid rules that are not conducive for our highly asynchronous work,
we'll focus on a few community-building aspects and hope these provide more incentives to participate.
There are a few ideas we can use to leverage the broader maintainer community to help with individual lessons.
Maintainer co-working sessions
Spotlight for lessons ("lessons of the month")
Implementation details
These are things that The Carpentries can do to help support the maintainers.
Maintainer Co-Working sessions
The maintainer community lead has been holding co-working sessions on the first Wednesday of the month
Lessons of the month
Can be mentioned to the broader Carpentries teaching community so we can get more feedback between lesson instructors and lesson maintainers.
We'll post a calendar for the year, and randomly assign a lesson to each month.
Month assignments are not fixed, you can request to have lessons moved to a month that better suits you
60 lessons (54 rounded up Point of contact for each lesson #11) across 12 months, roughly gives room for 5 lessons a month to be the "lessons of the month"
Instead of trying to coordinate swapping lessons, if a maintainer wants their lesson on a particular month, we'll just move them there.
Rationale
In general, these are some suggestions to get more community engagement within the maintainer community
and help progress stagnant issues and PRs.
Even though other maintainers would be able to "approve" and "comment" on PRs and Issues,
only the assigned maintainers to the lesson will have write access to the repository,
so at the end of the day, the final say still goes to the official lesson maintainers.
If a PR gets accepted and can still be improved on, I'm okay with another PR submission for an improvement.
Things can always be improved upon, and you don't need a "perfect" solution to a problem.
Assuming there is nothing "incorrect" with the PR or issue being discussed.
Maintainer Co-Working sessions
We have been doing this for almost a year now.
It serves as a way people can use to block off time to review Carpentries materials with other people.
They are low-stakes and serve as a good place to ask for help.
There is already time at the end of the monthly maintainer meetings for questions maintainers have.
This is really giving a separate and dedicated time for additional questions and actually working through a problem.
It has really helped with dealing with old issues and PRs when other co-maintainers are not being responsive.
Lessons of the month
This is one attempt that is low-stakes and tries to explicitly reach out to all of the lessons at least once a year.
Might motivate maintainers to ask for help in pushing through issues and PRs
Lesson maintainers can asynchronously post questions to the meeting notes that can be discussed/reviewed during any of the maintainer meetings.
Explicit month to do a mini bug bbq to close issues, ask questions, and review PRs
Potential issues
This does cause a blurring of lines between maintainers and lessons.
What constitutes as a "review" that other maintainers can approve?
How much say do other maintainers in issues?
This can potentially lead to overstepping and disenfranchise the actual maintainers of a lesson.
The text was updated successfully, but these errors were encountered:
Hi everyone:
This is part of the #15 refactoring, and is one of the solutions to help with issues and PRs going stale and giving some mechanism for maintainers to reach out beyond their direct co-maintainers for help and questions.
The Problem
they may not always be able to get (technical) help from their lesson co-maintainers.
Solution: Leverage the broader maintainer community
We understand that The Carpentries would not exist without all our volunteers.
The maintainers have different tasks and requirements than the instructors and trainers of the community.
Instead of creating rigid rules that are not conducive for our highly asynchronous work,
we'll focus on a few community-building aspects and hope these provide more incentives to participate.
There are a few ideas we can use to leverage the broader maintainer community to help with individual lessons.
Implementation details
These are things that The Carpentries can do to help support the maintainers.
Maintainer Co-Working sessions
Lessons of the month
Rationale
In general, these are some suggestions to get more community engagement within the maintainer community
and help progress stagnant issues and PRs.
Even though other maintainers would be able to "approve" and "comment" on PRs and Issues,
only the assigned maintainers to the lesson will have write access to the repository,
so at the end of the day, the final say still goes to the official lesson maintainers.
If a PR gets accepted and can still be improved on, I'm okay with another PR submission for an improvement.
Things can always be improved upon, and you don't need a "perfect" solution to a problem.
Assuming there is nothing "incorrect" with the PR or issue being discussed.
Maintainer Co-Working sessions
Lessons of the month
Potential issues
This does cause a blurring of lines between maintainers and lessons.
This can potentially lead to overstepping and disenfranchise the actual maintainers of a lesson.
The text was updated successfully, but these errors were encountered: