Discuss the future of the Technical Working Group (TWG)

I went ahead to start an MR to remove the TWG and then stumbled on the much wider scope of the TWG as opposed to merely core. Not sure how to bet tie this into the core team. Maybe not move the reposibilities that belonged with the TWG that are not core? But where to move them to?

Scope

The TWG's job to ensure that the necessary policies, procedures, and standards exist to address technical concerns affecting the Drupal community. This includes items that affect all projects, such as the Drupal coding standards, Git repository usage and licensing policies, and Drupal’s full-project approval process.

The TWG does not necessarily author and maintain these policies itself, but merely ensures that they exist, that they are well maintained, and that they are successful. To do so, they appoint and empower individuals or groups within the community to care for these policies and review them as needed.

The TWG may also develop guidelines and/or recommendations regarding the introduction of new tools and technologies for the benefit of the community. Where implementation of these recommendations is dependent on Drupal Association funding, Drupal.org integration, or significant investment from the infrastructure team, the TWG will work with these groups to evaluate feasibility of any particular option or recommendation.

Acceptance of TWG recommendations for key strategic issues may be subject to approval by the project lead (Dries Buytaert) or his designate(s).

Specific Duties of the TWG

• Ensure the Drupal project has effective policies, procedures, best practices, and standards to guide technical aspects within the Drupal community. The TWG does not set policies or standards for individual projects, including core.
• Provide clarification regarding intended interpretation of technical policies, as needed, to assist with conflicts or disagreements related to the interpretation of a technical policy, procedure, or standard maintained by the TWG.
• Ensure that changes to technical standards and policies are published and communicated out to the wider Drupal community.
• Provide recommendations to the Drupal Association, Drupal.org working groups, and infrastructure teams regarding proposed tool changes that will help accelerate contribution or otherwise enable the community.
• Establish best practices and recommendations regarding project namespace allocation, commit access to the Drupal.org Git repositories, the bug/issue/patch/review process, abandoned module process, and other key community workflows.
• Maintain a curated list of standards and policies maintained by the group, and propose additional standards and policies as the need for such is identified. Expansion of the TWG’s scope to include these proposed additions shall be subject to approval by Dries Buytaert and/or his designate(s).

Also a bit contradictory that the project lead is specified as responsible to appoint TWG members but the charter changes are set to be approved by Drupal Association board or their designates. Which is odd. There are some working groups that are under the Drupal Association, but this was not meant to be?!

One option would be to move coding standards to core committers, but leave everything else under the TWG and sort that out in a follow-up. If it's easy to extract that bit.

Drupal.org changes seems like the DA should be able to recruit people on an ad-hoc or regular basis for feedback on changes like gitlab, but to me that's not a 'working group'.

I wonder if it might be better to instead have several (all willing?) members of the core committer team volunteer in #3252921: Add members to the Coding Standard committe → and add them to the TWG rather than dissolving/incorporating it into the core.

Looking at the TWG charter it benifits from having individuals have to “put on a separate hat” and look at a situation from a neutral point. Neutrality is especially important with items like coding standards that impact not just Core but also Contrib.

Keeping the committee separate but adding several existing core commit would achieve the same immediate outcome of allowing issues to move forward while at the same time retain the ability for a community voice to be directly involved in the future.

@cmlara 🏆

@cmlara the problem that we have is there is no way for anyone except Dries to add or remove people from the TWG, and Dries does not follow the issue queue, which is why #3252921: Add members to the Coding Standard committe → was unresolved from 2021.

I think if we can say something like 'core committers and/or the existing members of the TWG can add people to the TWG' that would resolve the problem in a similar way to dissolving it into the committer team though. Given the TWG's remit is a bit beyond coding standards, that might even be an easier step as an interim measure, and we could still change things later.

the problem that we have is there is no way for anyone except Dries to add or remove people from the TWG, and Dries does not follow the issue queue,

I believe we are going to have that problem with this issue as well, it is going to take Dries approval to change the governance to transfer the responsibility of the TWG to the core commit team.

I just assumed that someone as part of the Governance process has a “direct line” to Dries to get him to look at issues (possibly the part of the rules where a maintainer may assign an issue to Dries) when they think it is time. If we don’t have that direct contact method and that is the holdup we have a bigger issue that I believe is way out of the scope of how this issue has been presented.

say something like 'core committers and/or the existing members of the TWG can add people to the TWG'

I think now we’re starting to touch on the the real issue, it sounds like the Governance process itself needs a way to appoint any position anywhere without requiring Dries direct prior consent. Dies could still maintain an override authority but wouldn’t need to make the decisions on a routine basis. The question of course is would Dries find that acceptable. This of course is a potentially politically complex change which may take time to discuss.

I have to imagine the discussion on that is easier for “we would like to add X,Y,Z to to the committee” vs “hey we want to dissolve your committee and decrease your technical oversight control” the former will be the least likely to stall out.

In this post I’m not trying to say Dries should or shouldn’t retain any of the control he currently has, just that if oversight breakdown is the cause trying to avoid it by transferring responsibilities is a stopgap measure at best, and should probaly be done in as narrow a manner as possible to get the job done until the larger discussion can be had.

I’ve been here before in other parts of my life, governance breakdowns are complex, hard to fix, and just get worse the more you centralize the control. I’ve had non-profits I’ve done volunteer work for take end runs around policy to get something done, yes it fixes the immediate issue but it closes down support longer term, especially when it’s in a policy that reduces the ability for members to get into contributing in a meaningful manner, making it even harder for the board to move forward, it ends up becoming a (long) death spiral.

Some of the changes to the governance are being discussed in #3059388: Officially replace the title BDFL with Project Lead and define as an arbitrator/tie breaker → .

I believe we are going to have that problem with this issue as well, it is going to take Dries approval to change the governance to transfer the responsibility of the TWG to the core commit team.

This was agreed last week at an in-person core committer offsite at which Dries was in attendance - this issue was opened as a result of that. But this was before Gábor looked at the detail of the TWG charter which makes it more complicated than simply absorbing the TWG into the core committer team as well as needing the DA to sign-off on charter changes. Which puts us back a step compared to where we thought we were.

However, there is a line in the current TWG charter that says:

Members are appointed by Dries Buytaert and/or his designate(s).

I think Dries' decision last week also applies to the core committer team being 'designates' as regards the TWG. This means that we should be fine to appoint people to the TWG without explicit sign-off on each new member from Dries.

Therefore the next steps probably look like:

1. Core committers, acting as 'designates' appoint a subset of core committers to the TWG.
2. The new TWG membership can start unblocking specific issues.
3. Sort out the governance changes in parallel.

I was at the same meeting as catch. I agree with the proposed steps in #9, they are straightforward and a common sense approach. The one thing I will add to 3) is a reminder to discuss places on the committee for non core committers.

I would update the Issue Summary but I am on holiday. :-)

I was able to read a bit more about this today on the train and I still agree with #9. It gives use the quickest way to to unblock issues which is the urgent problem we are trying to solve. And further to that the issues we are talking about are Coding Standards issues, there are no issues for TWG outside of that. Another reason I support this is to allow an opportunity to decide on the Coding Standards committee, an area where people who are not committers show keen interest.

I tried to make a branch that changed the TWG membership but I seem to have mucked it up and it has the Project Lead changes. I'll look at that later.

Landed #3252921: Add members to and remove members from the Technical Working Group → .

In my understanding the members of the TWG have full power to designate people to manage coding standards. Those people do not need to be TWG members. The coding standard process itself is also not defined in the charter, so that is within the realms of the TWG members to define. If the TWG members want to move the process to the core queue, they can. If they want to keep it where it is ( https://www.drupal.org/project/coding_standards → ) and appoint new maintainers there, that is their decision.

So we should figure out what kind of charter changes are needed.

Maybe the new TWG members would want to spend some time to figure out the new process and after that come back to amend the charter if the responsibilities should be moved out of the TWG for example? Since only the responsibility itself is defined in the charter and not the process, I think the process is fully unblocked now. The remaining question is whether the responsibility should be kept with the TWG or moved elsewhere. That will need Drupal Association (or a designate's) signoff, when we are ready to discuss that?

Retitled for that discussion. Makes sense?

Makes sense I think.

I started looking at the existing process and if we can adapt it (for example it doesn't make sense to have an dual approval process with core committers if most of the coding standards committee is core committers) on #3365085: Update the coding standards process on the project page → .

The changes for the Coding Standards committee are under way. I'm on the committee has we have the access needed to do the job, are actively working to follow the existing process while also discussing how to improve, and we are in the process of adding new members from across the community, and documenting what groups need to be represented. For me, the Coding Standards part of this issue is complete.

We can focus on the TWG. I am suggesting a new title.

Stumbled upon this. Fixing typo and expanding acronym.