To keep things going while the project application process is revamped, i nominate/request that Donna Benjamin, kattekrab, user 112345, be given a permission that allows her to give users the permission to approve project applications.
https://www.drupal.org/u/kattekrab
This will allow kattekrab to supplement championing the improvement of the process with recruiting people to become project application approvers, without the need for each person getting approved in this queue or whatever the process is supposed to be.
This is motivated by the fact that we have managed to have a major backlog of RTBC project applications (partially taken care of by Damien McKenna ) on top of all the projects stuck at earlier points in the process.
Thank you.
Comments
Comment #2
mlncn CreditAttribution: mlncn at Agaric commentedComment #3
mlhess CreditAttribution: mlhess as a volunteer commentedNormally, role requests need to be made by the user who will get the role. For this role, the user should provide a link to projects that have been reviewed.
RTBC projects still require a final review from a project admin.
Comment #4
kattekrab CreditAttribution: kattekrab as a volunteer commented@mlhess - how can we break the stalemate and really fix the project application review process?
Comment #5
mlncn CreditAttribution: mlncn at Agaric commentedYeah, this isn't about an accomplished reviewer being able to vouch for other reviewers. This is about kattekrab, being a person working on the project application process overhaul and connected to many people in the trenches and in the reform camp, being able to identify those who can do reviews-- in consultation with others. I don't feel it has to be about proving her bona fides in reviews themselves.
And yes, the process is acknowledged broken and reviews are going to be greatly downplayed in any replacement because they simply haven't worked, so, yeah, not necessarily the best criteria to go with?
Comment #6
mlncn CreditAttribution: mlncn at Agaric commentedBy the way where is the criterion documented ("provide a link to projects that have been reviewed")? For getting the project approver role, even, as i doubt the project approver approver role is documented :-P
Also to be clear, this is about giving the permission to give the final RTBC review.
Thank you!
Comment #7
mlhess CreditAttribution: mlhess as a volunteer commentedThere are 3 proposals that address this that have been approved by all parties but require a combination of DA staff time and tech expertise to work on the issue. I made another proposal that would remove a large amount of the manual work privately and can make it publicly once I have the time to write it up, this would at least resolve the security team hold ups.
@kattekrab, if you want to setup a call to discuss this week, I would be happy to do so and get your feedback on my newer idea and find the issues that document the current plan.
The discussion of this issue should stay on the issue linked in the summary.
Comment #8
yoroy CreditAttribution: yoroy at Roy Scholten commentedYou've got a wonderful and very responsible person with the right track record here who wants to help out. I know we're in a domain here where formality and following procedure is necessary, but the very least we can do is acknowledge that this proposal can be discussed right now. So setting back to active.
Comment #9
BozHogan CreditAttribution: BozHogan as a volunteer commentedBen,
Is this something I can help with? Or would the learning/training curve make it an unwise use of resources. I'll be back in a couple months, so I can use that time to get up to speed, and can hit the ground running when I get back.
Let me know if you think it's a good or bad idea.
Zhuhao,
Boz
PS. I've got an email in to you.
Comment #10
mlncn CreditAttribution: mlncn at Agaric commentedNote: I am in my fifth hour of reviewing RTBC project applications.
And the last post on too many are comments such as this:
At the very least, kattekrab needs to be able to see who is currently approved to give git vetted user status, and a very clear process for how other people can apply for this role. But again, i think we should give her the power to deputize people with this role. Donna is our best bridge between putting out the fire that is the project application queue and policy to fix it, and should be given tools to have better insight into it. But the focus of this issue is very much preventing the current process from grinding to a halt while progress is made (we pray) toward the proposals offering more permanent improvements.
Comment #11
mlncn CreditAttribution: mlncn at Agaric commentedEight hours of reviews and i'm done with the RTBC queue— again, it took that much time even after Damien McKenna made a major dent in it just yesterday. Now we can focus on the needs review queue.
In a month the RTBC queue will be piled up again unless preventative measures are taken—like giving kattekrab the tools to recruit more reviewers / poke existing reviewers—in the interim while longer-term proposals are worked out.
After this all-nighter, i'm back to multiple work deadlines. This. Is. Not. Sustainable. Even for the short term. Thanks for listening.
Comment #12
mlhess CreditAttribution: mlhess as a volunteer commentedThank you for your help in the queue!
I am not sure how giving this role allows a user to recruit more reviewers / poke existing reviewers. The role does not give access to any information that would help with that task.
I have invited kattekrab to a conference call to discuss this further, so lets put this on hold until that happens.
Comment #13
gregglesDrupal.org process is to create an issue each time someone gets the role granted. That seems like a pretty small roadblock in the process and a good procedure for this site and any other that accepts credit cards. So, even if we do give kattekrab the role required to grant the "git administrator" role we still need that. I'm happy to help with that too.
There's a wiki page of that here but it's probably a bit out of date and includes some folks who perform this task even though they have a different role than just the "git administrator".
But here's a list of people with "git administrator" role I *just* pulled from the d.o permissions page.
The process I've seen is something like:
I'm +1 to getting more people involved in the process and +1 for kattekrab in general helping out with this area. I'm not sure this specific proposal is the best way to achieve that.
I updated the title to include the actual roles required. The "administrator" role is something where DA should weigh in prior to approval.
Comment #14
kattekrab CreditAttribution: kattekrab as a volunteer and at Catalyst IT commented@greggles - Thank you so much for this. Very useful, very clarifying.
For those who may not be aware...
I'm on the board of the Drupal Association (elected in 2012, since appointed, currently serving 2nd and final term)
I was the chair of the Community Working Group - but stepped down recently.
I seem to recall 3 or 4 of the issues raised with the community working group in recent years had a root cause in the frustration around the PAR - this is one of the reasons I am passionate about resolving the issue.
I am not a developer, I can not review code.
I am a project facilitator - and fighting to tear down road blocks is one of the things I do, professionally.
This issue is intractable, and has been, since at least 2010, probably earlier.
Angela "webchick" Byron, even gave up on this.
I don't know if giving me administrator access to Drupal.org will help fix this issue, or not, but if adding a few more people to that list who have track record, and are willing to actually spend time reviewing project applications with RTBC and "Needs review" statuses, then I'd be happy to work on guidelines, and process around what's involved.
But frankly... I've already had people volunteer to help, only to back out when it meant they had to do more work just to be "approved" to help. (That is, go review 20 modules, have your reviews assessed at each step, and then be blessed).
On the other hand, if @greggles and @mlhess as security team leads do not trust me, then I am 100% fine with closing this issue.
Comment #15
DamienMcKenna[updated, for clarification] As an active contributor, it can be easier to join the security team than to become approved to approve git access. I believe the bar for becoming an approver should be reduced.
Comment #16
DamienMcKenna(I updated my comment to clarify my point)
There are multiple problems within multiple levels of this mess we've created for ourselves. kattekrab is a wonderful person who has done and continues to do great things for our community, but giving her access to something won't fix the underlying problems.
I believe a few people are working on new proposals, and some other things are underway, lets give them some time to finish what they're working on and then see whether this request is even needed.
Comment #17
gregglesI should have clarified "DA technology/engineering team" should weigh in. I'm aware of your role with the DA, but it seems separate from the decision making about granting roles.
Sure, that makes sense to me, as long as the appropriate process is followed. I mention having the DA review the administrator access because I know they recently did a close review of that role and it was taken away from me, that's all I'm saying ;) If the goal is having people do reviews and you working on the guidelines/process then I don't see a role as a blocker to that effort, but if it seems likely to help then that's great.
Great!
I'm confused by the motivations for this decision. If people don't like doing dozens or hundreds of project reviews then they don't actually want to help with reviews and don't need the git administrator role. If they dislike a process of getting feedback from team-mates I'm not sure they should work in a process where policies adjust and adapt based on conversations and retrospectives.
From #15:
That's not the impression I get. I'd say it's a very similar process, and the security team's process is a lot more opaque (I wish it were less opaque, but the nature of the role is a bit tricky).
To judge if this ability to grant roles is a blocker, let's maybe consider the question: are there any individuals who wanted to become a git administrator, had gone through the current process, were well suited to the role, who were declined or blocked? I follow the project application group on g.d.o quite closely, but I don't follow the webmasters/infra/project application queues very closely any more, so I'm honestly asking. I haven't seen that scenario, but perhaps it is out there and indeed needs to be addressed.
Comment #18
gdemetI don't think this is a question so much of whether or not we trust Donna to have these privileges, but rather whether giving her the ability to deputize reviewers will adequately address the immediate issues with project review.
I am also a non-technical contributor and am not well-versed in all of the details of this issue, but from where I sit, it sounds like we have issues both with our processes and with our tools, and that those are inextricably linked. It sounds like everyone here is aware that what is being proposed in this issue would be a temporary stop-gap measure at best until a more better and more permanent solution can be found, and would likely still require the involvement of other individuals.
In my role as acting chair of the CWG, I can definitely back up what Donna is saying about the current process leading to issues in the community. We are currently conducting a survey of Drupal contributors and the project application review process has repeatedly come up as one of the top things that needs to be changed to improve the Drupal contributor experience.
I know pretty much everyone in this issue, and I know that they all have the best interests of the project and community at heart. I don't think that Michael's request to have a call with Donna first is an unreasonable one, and I am optimistic that at least a short-term solution could be found pretty quickly as part of a real-time conversation, which could also involve other relevant members of the community (having more real-time conversations and fewer issue queue conversations is another suggestion that's come up from a number of the people who have taken our survey so far).
Comment #19
kevincrafts CreditAttribution: kevincrafts commentedRegarding #13...
How often is that git administrator list updated? Should users that are no longer contributing to Drupal have their git administrator role removed?
Comment #20
gregglesre #19 - Yes, that makes sense to me. I'm not sure process might exist on d.o in general for that kind of task. It seems like something worth taking on as a group and separately from this issue.
Comment #21
kattekrab CreditAttribution: kattekrab as a volunteer commentedI've just got off a call with a number of the folk here. I am heartened.
Giving me administrator privs will not fix this issue - but kudos to @mlncn for throwing down the gauntlet - because it has moved the needle.
In the immediate short term, we're still going to need to review applications. @mlhess and I are going to reach out to the existing list and ask for some support.
I'm also going to meet with @hestenet and @mlhess to put together a work plan on what needs to happen next to move the revamp along in parallel.
Thanks to all of you for the time, energy and commitment to resolve this.
Closing this issue now.