Volunteering as a D7 core committer (@mcdruid)

This should have a patch modifying MAINTAINERS.txt so there is something to RTBC.

+1 on this.

+1, I have rolled mcdruid into my patch here:
#3086286-18: Offering to maintain Drupal core (@joseph.olstad)

Lets roll with webchicks plan, Pol as primary maintainer, mcdruid and myself as provisional branch committers.

+1 from me here, I've worked with Drew on a couple of issues in the security team and a couple of issues in core.

I've found him to be skilled, thorough, measured and professional.

I'll make sure this has surfaced in the core committer channels

I think we should retain separate issues

I’ve only worked with mcdruid recently in #3074666: [D7] Password reset form has no flood protection, that I remember. In that, and the parent D8 issue, I’ve been impressed with their attention to detail and patience, and success in landing a patch.

And he is already on the security team: https://security.drupal.org/team-members

Q) What is the urgency for a new Drupal 7 core maintainer team?

A) To move forward with php 7.3.x and 7.4.x compatibility in the 7.x branch so that all of contrib can start testing against php 7.4.x. Once we do this we will be able to allow contrib to start testing against php 7.4.x. This core issue is blocking a big part of contrib. We have the testing infrastructure in place, let's make more use of it.

For what it's worth I find mcdruid's contributions to be extremely conscientious and thorough, and I'd welcome someone of such calibre to take on the D7 commit queue.

Assigning to Dries to take a look, as this has to do with adding folks to the committer team.

Sorry, just some issue housekeeping.

Thanks @mcdruid! I too have found mcdruid's work for the Security Team relaible, communicative, respectful, and attentive to detail.

@mcdruid, can you confirm you've read, understand, and agree to follow the whole governance doc on Core maintainership? Link here:
https://www.drupal.org/contribute/core/maintainers

These two paragraphs are especially important:

Maintainers with commit access need additional skills. They are reliable, decisive when needed, open to feedback, and able to give others feedback constructively. They also need significant prior experience participating broadly in core issues (usually at least a year).

It's generally desired to have at least two people in any given maintainership role, in order to prevent burnout and to help ensure there are ample people available for unblocking a given decision; however, this is not a hard requirement. Maintainers are expected to give clear, objective reasons and actionable feedback in the event they push back on a given change.

Be sure to review these section as well:
https://www.drupal.org/contribute/core/maintainers#decisions

And finally, descriptions of all the committer roles are documented here: https://www.drupal.org/contribute/core/maintainers#who-are-maintainers

@mcdruid, Can you read over that governance doc when possible, and confirm here on the issue that you fit the description and are willing to have those responsibilities?

Also, have you given some thought about whether you'd be a product, framework, or release manager? Based on your issue summary, I'd say you would make a good candidate for a provisional release manager.

Thanks so much for this proposal!

It's great to see enthusiasm for this role! In my opinion, there's a lot of easy work to do for the first release or two, great code provided to us by the community. Items with RTBC consensus in some cases greater than 24 months. It's important that we as core maintainers consider seriously the efforts of the community to improve this product for everyone and if we need to provide a reason for postponning an improvement rather than completely ignoring them. By taking action we can restore the confidence of the community, replace apathy with optimism, replace stagnation with collaboration and progress. Let us serve the community that has provided wealth to us all!

If we as a team can together do as much work as David Rothstein and FabianX, then we will have great success.

Thanks McDruid for stepping forward, I will do what I can to assist you in this endeavour. I would like to be one of your close colleagues, with equal status, with access to the slack channel so that we can discuss and plan releases. This is a big responsibility so it would be great to share the load.

I think that the BDFL should give all three of us a chance to move things forward as a team and should it not work out after a month or two then by all means can reverse the decision.

Give all three of us a chance, and see what happens.

If not, then I wish McDruid good luck by himself. What I ask of core maintainers, is rather than drop off the face of the earth, that they resign like David Rothstein did, as a call to others to take over. What we've seen recently is complete neglect and I think that is unacceptable and selfish on the part of the 'active' maintainers. If you're unable to maintain the project, please step down and let everyone know so that others will see and hear the call to action, so that others will be solicited to step forward and continue what we need to continue doing. It's not a dead project, this is a project that is very much alive, it is alive as long as people are willing to use it, as long as people are willing to support it and as long as people are motivated by it. Do not think of your own selfish reasons for your actions, think of the community, serve the community. This is my philosophy. As long as there are numerous high quality RTBC issues waiting, there's unfinished business. As long as there's unfinished work, there's work to do. If there's work to do, we need someone responsible who is willing to do it. If someone is unable to do the work, they need to step down and solicit someone else to do the work for them. Lets replace neglect with passion and hard work. One of the greatest responsibilities of a maintainer is to have the humility to step down and ask for someone else to take his place. For this reason I have the highest respect for David Rothstein, he gave it everything he had and he did it for years, and when he was done, he told everyone and let everyone know, he didn't just fall off and ignore everyone. He said, I'm done, thanks, I am passing the torch now.

Thanks for caring and for listenning,
Joseph Olstad

I am +1 for McDruid as release manager.

I also think he is perfect for the role described and the stage where Drupal 7 is at right now.

I think an LTS approach will work well at this Point.

I never understood Gabors approach to Drupal 6 in the last years, but now I do — being in essentially the same position.

Thanks for volunteering to help.

I’ll be at DrupalCon and hope we can prepare a new bugfix release while there.

FabianX is back and mcdruid seems to be the chosen one. Let's see what they can do.

It sounds like FabianX and mcdruid could build the team that we need to move issues forward in a timely manner. Otherwise we risk fragmentation. We are stronger as a whole than individually. With that said, fragmentation is a real risk and I hope that it doesn't come to that. Drupal.org has been good to us all, let's keep the momentum going and focus on having more great success! Delay the EOL of D7, progress things forward organically, this is what I am projecting.

Thanks,
Joseph Olstad

I actually feel we can move this to RTBC. This application has +1s from numerous core committers and security team members, as well as the currently active D7 maintainer. Way to go, @mcdruid!

I've sent Dries an email with a summary of all of this, but please remember that DrupalCon Europe (and therefore the Driesnote) is imminent, so I can't speak to the timing of when exactly he'll be able to make the changes.

Congratulations @mcdruid!

please remember that DrupalCon Europe (and therefore the Driesnote) is imminent, so I can't speak to the timing of when exactly he'll be able to make the changes.

If we could add this news to the Driesnote that'd be great. There are many D7 site owners out there and with the upcoming D7 LTS this would distill positive energy all around 😁

Congrats mcdruid, I've spent some time reviewing and triaging 7.68 target issues and pending commit issues. I set one issue to needs work (needs tests) , reviewed a lot of others and provided justification for the maintain RTBC so that it will help you make quicker decisions.

Should you have feedback on my triage work, you can contact me. I was basing my triage work on suggestions that FabianX gave me here:

If you want to do the hard work of the core committer, then indeed going through the whole list of RTBC issues and check:

- Are they (the same) in D8? Yes => Add the tag
- Do they have tests? => Yes => Add the tag

No => Needs work + some nice text why it needs work and why it's important

I wasn't sure which tag he was referring to, I want to always use the same tag.
Right now, for highest priority items that are RTBC and approved by core maintainers they get the 'Pending Drupal 7 commit' tag. I did take liberty to approve a few and add the tag with justification of course.

There's also the Drupal 7.68 target tag

For now, I've only included RTBC issues in the Drupal 7.68 target tag.

Basically the rule I'm using is:

If the fix has tests or doesn't need them and was justifyable
The fix was already made in D8
And there's no change record required

then those issues remain as RTBC

if they are all of the above and have special priority, or were identified by a core maintainer as pending commit then they get the 'Pending Drupal 7 commit' tag as well

This is my decision, and I'm a big +1 on adding @mcdruid as a Drupal 7 core committer. Approved.

This is both important and urgent; Drupal 7 needs some attention. Thanks for your help, @mcdruid.

I just gave @mcdruid commit access to Drupal 7. Maybe he can commit this patch as his first act? :)

Congratulations @mcdruid.

I am contracting at the government of Canada and we are looking forward to a Drupal 7.68 release and also long live to Drupal 7 without end of life.