Co-maintenance plan for the Webform project [#3201435]

Problem/Motivation

Per the comments section of a recent jrockowitz blog post:

I always welcome co-maintainers to the Webform module. Maintaining this module is a significant undertaking. In the next few months, I will try to figure out a plan/process for sustaining the Webform module.

Given the background reading from the current maintainer on availability (1, 2, 3), I've created this issue for transparency to encompass the plan/process for a more distributed approach to sustain the Webform project.

Proposed resolution

@tbd

Remaining tasks

@likely a lot of tasks.

Comments

Comment #1

3 March 2021 at 17:08

Webbeh created an issue. See original summary.

Comment #2

jrockowitz commented 3 March 2021 at 20:53

I think the most important thing is for people to read co-maintaining projects.

Comment #3

paulocs

Portuguese, Brazil

Belo Horizonte

commented 4 March 2021 at 13:18

Hello @jrockowitz,

I read your post "Drupal or not Drupal". The Drupal Community will lose a lot without your contributions. :(

I have interesting to help maintain the Webform module and keep it updated. I think it is very important to have someone available to contribute with the big webform module.

Please let me know what you think and if you have any suggestion. :)

Thanks!

Comment #4

Webbeh

he/him/his

Georgia, USA

commented 4 March 2021 at 13:23

I think @jrockowitz's comment in #3201435-2: Co-maintenance plan for the Webform project might need a little expansion to describe what a potential co-maintainer would need to accomplish, as Webform is a fairly exhaustive and widely used contrib project.

Just to be clear, this is not the issue for folks to blindly apply for co-maintainer status unless they've thoroughly read the documentation linked and have demonstrated focus on understanding the code underlying Webform and have already contributed back to the issue queue and project growth/releases.

Bolding for emphasis:

Everyone can submit patches to every project at any time. Co-maintainers are individuals who can commit patches and thus change the code of a project. If a project is not being maintained, you may be able to become the maintainer. Some considerations:

Commit access is not granted blindly. Applicants should have already read each issue and participated in many issues in a project's queue, helped with support requests, provided patches, and be involved in architectural and technical discussions. Ideally, applicants are also available in IRC or other instant messaging tools used by the project maintainers.
Project maintainers should have committed 3-4 of your patches without any objections or remarks. Too simple patches do not count.
Create an issue with the title Applying for commit access and describe your motivation.

@jrockowitz, let me know if I'm off-base here, but I want to make sure to keep this issue as focused and goal-oriented as possible. If this is the intent, I'll update the issue description with a more thorough explanation of how folks can begin contributing back towards becoming a co-maintainer.

Comment #5

paulocs

Portuguese, Brazil

Belo Horizonte

commented 4 March 2021 at 14:46

I totally agree with you @Webbeh! I commented because I think I can help.
I know how important Webform is and I know it is a big responsibility.

I'm always trying to help the Drupal Community as I have time (you can see the issues I've worked on).
I really would like to know what are the plans for the module and I'm making myself available. Just it :)

Comment #6

jrockowitz commented 4 March 2021 at 16:27

@Webbeh Your comment in #4 is spot-on and helps take some of the burdens off of me to sort out the roles for "co-maintainers" of the Webform module.

Generally, a co-maintainer understands the codebase and quality expectations. For example, I spend a fair amount of time writing automated tests.

At the same time, I could see a non-technical maintainer helping to wrangle the project page and issue queue, and they need only the permissions to do these tasks.

For reference, I will list out the different maintainer permissions, and maybe these will help define the co-maintainer roles.

Write to VCS: Allows a user to commit or push to the repository associated with this project.
Edit project: Allows a user to edit a project and modify its settings.
Administer maintainers: Allows a user to add and remove other project maintainers and to modify their permissions.
Maintain issues: Allows a user to assign issues to other issue maintainers for this project.
Administer releases: Allows a user to create and update releases, and to control which branches are recommended or supported.