@CCicalese_WMF could you clarify if this is just for stable releases, e.g. 1.37.0, or also security/maintenance releases? And is this about switching the responsibility for organizing the release (shepherding and backporting patches), or the actual technical release (running make-release2.py) or both?

In T293323#7430272, @Legoktm wrote:

@CCicalese_WMF could you clarify if this is just for stable releases, e.g. 1.37.0, or also security/maintenance releases?

Certain aspects of security releases would still need to be done in house, but the goal would be to transition as much as possible of the mechanics.

And is this about switching the responsibility for organizing the release (shepherding and backporting patches), or the actual technical release (running make-release2.py) or both?

Both.

There are myriad details that will need to be worked out and documented. That would be the next phase of this process. Members of the MediaWiki Stakeholders' Group plan to participate in the upcoming MediaWiki 1.37 release in order to gather enough information to generate a detailed task list with assignment of responsibilities that would form the basis of a Memorandum of Understanding.

AIUI the proposal names these goals/opportunities

1. More predictable release schedule.
2. A better release format(?)
3. WMF would have more time and resources for other things.
4. Improved communication between WMF developers and the 3rd-party MediaWiki community.
5. MediaWiki developers would not be slowed down by the Stable Interface Policy

I can see how #4 would work (I think MWStake has already been fairly successful at facilitating better exchange of information between the WMF and some parts of the developer community), though with the caveat that MWStake has positioned itself into representing a specific part of the MediaWiki community (professional MediaWiki developers and organizations with dedicated MediaWiki staff), and doesn't have much track record representing others. (Although one could argue those are exactly the ones for whom a better release process would be important.) I'm not sure I see the connection to the other four stated goals/benefits though.

#2 and #5 aren't really related to which organization does the releases. I guess the implication here is that MWStake would rethink the release format and the associated policies and come up with something better; it's hard to evaluate that without any specifics though, and it could be done with or without transitioning release management to another org.

#3 is a matter of funding. Presumably WMF staff doing the releasing is not especially expensive; another organization would incur comparable costs by doing it. If that's covered from Wikimedia movement funds, the WMF will not have more time and resources; they will just be spent elsewhere. The alternative is MWStake doing it on a volunteer or partially volunteer basis (in which case goals like a more predictable schedule seem somewhat over-ambitious), or covering it from some other source of funding, presumably from companies using MediaWiki. The latter would be a reasonable long-term goal, but how realistic is it today? In 2014, the WMF paid $75K per year for release management; MWStake was incorporated last year, and guessing from the sponsors and fees page its current industry funding might be somewhere in the $5K-$25K range. So that seems fairly ambitious.

#1 is partily a matter of sufficient resourcing (see above), partly of organizational maturity (with all due respect to MWStake, it would not be an improvement in that regard), partly of focus. I can see how MWStake could pay more attention to release management than the WMF does currently; but I doubt releasing could be done without coordinating with developers of MediaWiki core, the most active of whom are WMF staff members. So communication and coordination would become more complicated; one problem would be traded for another.

All that is not to say I would think such a transfer of responsibilities a bad idea (having a dedicated org in the Wikimedia universe to focus on third-party MediaWiki users makes strategic sense), I'm just not sure about the benefits listed here.

As I understand this proposal -- and maybe this is naive optimism -- the idea would be that MW would still branch on a rigorous schedule (every six months, with a "LTS" every two years) but that it would be hands-off past that point; all the shepherding necessary to actually alpha/beta/rc package-and-test this would be handed-off to MWStake. I agree with @Tgr that I'm not sure this isn't just moving money and time from one pile to another, but if there are other good reasons to do this, it would indeed (mildly) accomplish goal #5 in so far as deprecations and removals could be done "like clockwork" on master after the release is branched, even if (due to reality intruding) the actual *release* of that branched code was delayed.

I will note that there are a number of "core" extensions which maintain compatibility with LTS releases, not just "current master". Translate is probably the most important of these. I would like to see responsibility for maintaining LTS compatibility for these extensions transition as well. Whenever I have to make a deprecation-policy-type-of-change (say, just renaming a method from foo to bar) it's an easy codesearch-and-replace for about 90% of the code covered by codesearch, but that last 10% is a slog: it includes both code which is covered by codesearch but has a non-WMF CI system, as well as code which maintains LTS compatibility (for which just bumping the required version in extension.json is not sufficient)... and some code which does both (maintains LTS compatibility in a non-WMF system). (I know that policy says I'm not *required* to do anything to facilitate/port most of the code which falls in that 10%, but I try to break as few things as possible.)

Thank you for the feedback, @Tgr and @cscott. Note that this task is related to the Problem Statement phase of the process. As noted at T293323#7430328, specific solutions will be addressed in the next phase. That being said, your feedback is very valuable in helping to shape the decisions.

In T293323#7474175, @Tgr wrote:

#3 is a matter of funding. Presumably WMF staff doing the releasing is not especially expensive; another organization would incur comparable costs by doing it. If that's covered from Wikimedia movement funds, the WMF will not have more time and resources; they will just be spent elsewhere.

AIUI, this proposal does not say that the releases would be covered by WMF movement funds. That was tried in the past and rejected.

The alternative is MWStake doing it on a volunteer or partially volunteer basis (in which case goals like a more predictable schedule seem somewhat over-ambitious), or covering it from some other source of funding, presumably from companies using MediaWiki. The latter would be a reasonable long-term goal, but how realistic is it today?

MWStake has two different resources that it will use to handle releases:

1. MWStake members who will provide their own paid staff to this task initially. That is realistic today since we have enough commitment for that now.
2. Raising money from users of the MW distribution to support these roles. In the aspect of predictable releases, that would make MWStake accountable to users of the MW releases. Right now, there is no way to directly tie contributions to the WMF to MW releases if that is what you are interested in supporting. Moving the funding source to MWStake would provide users who want to support the software a way to do that. I have had clients ask me if there was a way to do this in the past, and this would open up a channel for people to do this.

In 2014, the WMF paid $75K per year for release management; MWStake was incorporated last year, and guessing from the sponsors and fees page its current industry funding might be somewhere in the $5K-$25K range. So that seems fairly ambitious.

MWStake has corporate members who have been users and providers of MW services for several years. It is these members who will provide the initial support for releases through personnel and financial support. Once MWStake has established itself as the distributor for MW, it expects to be able to tap into other resources.

I have two concerns:

I'm concerned with the 'optics' of WMF stepping away from producing releases for the software to the community of Enterprises and Institutions who use the software for Knowledge Management. I would think libraries, software projects, enterprises and others would be more apprehensive about using the software for any serious use without the "vendor" supplying official releases.

One of the stated friction points is the ability to rapidly evolve the codebase against the requirements of the stable interface policy. If the WMF wants to rapidly evolve the code, and isn't responsible for producing releases, doesn't this mean that MWStake would be disadvantaged in their ability to produce regular 6mo releases that do obey the stable interface policy? In other words, it seems the real issue is to evolve the stable interface policy by announcing the intention to break compatibility more often; help extension developers keep their code compatible; and 3rd-parties should be prepared for more rigorous upgrade efforts.

This question is being posed as part of the technical decision forum process which has yet to fill any community seats. Some of us try to proxy vote for what we understand technical community including the poorly defined "third party" users are interested in, but without actual representation of these groups in the TDF process this proposal seems more like an internal Foundation referendum on discontinuing tarball releases than a MediaWiki community discussion on adjusting release practices and responsible parties.

@bd808 fwiw, I'm one of the community seats on the TDF. I would love to talk to you offline about this if you want to discuss more. MediaWiki-Stakeholders-Group is not a perfect representative for 3rd party users, but we're trying.

In T293323#7485969, @MarkAHershberger wrote:

@bd808 fwiw, I'm one of the community seats on the TDF.

This membership is not disclosed on https://www.mediawiki.org/wiki/Technical_Decision_Forum#Forum_Members

In T293323#7485975, @bd808 wrote:

This membership is not disclosed on https://www.mediawiki.org/wiki/Technical_Decision_Forum#Forum_Members

Thanks for pointing that out. Fixed.

In T293323#7485969, @MarkAHershberger wrote:

fwiw, I'm one of the community seats on the TDF

[off-topic] Huh? That page describes a public appointment process. Where did this happen? Why have I not heard anything about it?

In T293323#7485761, @freephile wrote:

I have two concerns:

I'm concerned with the 'optics' of WMF stepping away from producing releases for the software to the community of Enterprises and Institutions who use the software for Knowledge Management.

There is a precedent for the releases being produced outside WMF in the past. The plan is for there to be a document that will lay out the responsibilities for releases, and WMF will retain some of those responsibilities, such as providing the infrastructure and accounts. The WMF is not stepping away from producing releases but instead would be allowing an organization with more involvement in the community of non-Wikimedia MediaWiki users to do so for the benefit of that community.

I would think libraries, software projects, enterprises and others would be more apprehensive about using the software for any serious use without the "vendor" supplying official releases.

The WMF is not the vendor in a traditional sense. Their primary interest in MediaWiki is rightly related to its use for Wikimedia projects, and they are not consumers of the current tarball releases. There is a benefit to the releases being produced by an organization more aligned to the needs of the consumers of those releases. That being said, the MediaWiki Stakeholders' Group would definitely benefit from participation from a broader set of those consumers.

One of the stated friction points is the ability to rapidly evolve the codebase against the requirements of the stable interface policy. If the WMF wants to rapidly evolve the code, and isn't responsible for producing releases, doesn't this mean that MWStake would be disadvantaged in their ability to produce regular 6mo releases that do obey the stable interface policy? In other words, it seems the real issue is to evolve the stable interface policy by announcing the intention to break compatibility more often; help extension developers keep their code compatible; and 3rd-parties should be prepared for more rigorous upgrade efforts.

There will still be a stable interface policy. It would be revisted to see if there are any cases in which it could be relaxed (e.g. if there is no affected code remaining in all places noted by codesearch - which would admittedly leave out private repos, so would need discussion). This would limit the impact on third parties by ensuring that dependent code had actually been remediated already before a release. This may also result in strengthening the stable interface policy is some places (e.g. banning new deprecations within X weeks of a release being cut). And, it would provide an opportunity to revisit some current confusion and annoyances about extension/skin compatibility policies and how extension/skin branches are cut and maintained. The intention is for this to be done in a way that provides a net benefit to the consumers of the releases.

Note: I've edited the task description so that it correctly includes "users" in the make up of the MediaWiki Stakeholder's group as the front page of mwstake.org does.

Hello, thanks for the problem statement, and the discussion.

I've said it in the feedback form, but seeing discussion here, I realize that the phabricator comment might be preferred in case of the problem statement overview.
I have to admit I fail to identify what really is the problem that this problem statement aims to provide an overview of? I believe @Tgr had a good take on attempting to list few possible problems you folks might mean here, I could possible see a few more in the text. Is it just me, or would it actually make sense to be more clear about the WHAT?

Discussion in the comments above seems to get into the details of a possible solution which was rightfully pointed out is not part of the "problem statement" phase. I do see however that even the problem statement seems to be mixing up the solution and the problem(s). Even the problem statement's title "Transitioning Responsibility for MediaWiki Releases" is clearly in the solution land, isn't it?

To finish on the constructive note - I don't want to come across as a complainer, I appreciate the effort put into preparing this: WMDE clearly is a stakeholder ("C" in terms of RACI matrix I'd say) in many possible topics related to Mediawiki releases. We will be more than happy to provide input on our requirements (on the later stage), but also to help identify issues with the current Mediawiki releasing process, as we certainly could name one or two. I do not understand however if that problem statement is the call to action "there are issues with Mediawiki releases, let's identify them". If there was an interest to define the problem statement (maybe there are mutliple problems here even), I'd happily serve as a rubber duck to bounce any ideas against.

Thank you for the feedback, @WMDE-leszek. I do think that your comments about the problem statement venturing into the solution space are fair. Part of the problem is the questions which must be answered. "What does the future look like if this is achieved?" does not define the problem but rather the world in which the problem has been solved somehow. It is difficult to address that without at least hinting at a solution.

While I would prefer that the process not get stalled on revising this problem statement at this point, I would indeed be very interested to hear your thoughts on any additional issues with the current MediaWiki releasing process that should be considered. Please feel free to share them here. And, without a doubt, WMDE's input on the proposed solution will be welcome and quite valuable.

I primarily depend upon tarball MediaWiki releases in my role as Debian maintainer of the "mediawiki" package. As part of this work, I've spent a decent amount of time improving the release process by working with Chad, Reedy, and others including writing make-release2.py, to fix many problems we've had with generating the tarballs, figuring out the /vendor process, weird misc issues like T263866 and T257102 and more. Then there's stuff not directly related to the release but IMO had a significant impact like getting Postgres running in CI to prevent regressions. The Debian package has a full end-to-end installer-to-editing test suite that time permitting is run against tarballs before they're released and have caught real regressions in the past.

My main priority is ensuring the security release process remains functional and stable with minimal regressions, which is the main expectation in Debian. Things have improved significantly with the regularly scheduled quarterly releases, CVEs assigned ahead of time, a tracking table so patches don't accidentally get dropped, but we are still in need of better testing (e.g. T226945, T270452, T263883), and more people poking at this is exactly what we need.

I believe that 90% of improvements to the release process and releases themselves can be done by just having people contribute the way people already do to MediaWiki - commenting on bugs, discussing on mailing lists, and submitting patches. If MWStake wants to contribute more to releases, that's fantastic, really. Please, just start helping :) ...and then we can empower more people to do more advanced work that requires specific permissions or roles.

Some specific comments:

The timing of MediaWiki releases is currently unpredictable. There are few dedicated Wikimedia Foundation resources for producing the third party MediaWiki releases. Staff participate in the release process largely as a side effort, not an integral part of their assigned role. Thus, releases are generated as time permits.

Please provide some evidence for "unpredictable". AFAIK all security releases have been roughly on time, the only things that have slipped are stable releases. Some of those slips were pretty reasonable and understandable because of COVID, with outstanding blockers preventing a release from going out. Most MWStake members are not MediaWiki *core* developers AFAICT - what is the plan for getting those blockers fixed when they inevitably arise?

I might be too deep in the Debian mindset ("it'll be released when it's ready"), but what's the end goal if we do have predictable releases? Even then I wouldn't expect all or most extensions to immediately support the new version, the ecosystem takes time to update, just like when a new Python version comes out, it takes a bit of time for various Python libraries to publish their compatible versions.

Some core code changes must currently be done phased in over time. Per the Stable Interface Policy deprecation process, certain changes may not be made immediately but must go through a deprecation process tied to releases. Delays in MediaWiki releases push the timeline of deprecation back. This proposal would allow core MediaWiki developers to move more aggressively in some areas of the MediaWiki core codebase as more active involvement from the third party MediaWiki community and extension developers serving that community would provide feedback on critical changes, reducing unnecessary delays.

It is quite surprising to hear that MWStake wants MediaWiki core to move more aggressively in deprecating and making breaking changes - I was under the impression that the exact opposite was wanted. I also don't see how this is a problem that will be fixed here, the branching schedule is run by Release Engineering, who make the bump from e.g. 1.37.0-wmf.X to 1.38.0-wmf.1, which is what enables people to merge the next round of deprecations and removals.

In T293323#7485996, @Majavah wrote:

In T293323#7485969, @MarkAHershberger wrote:

fwiw, I'm one of the community seats on the TDF

[off-topic] Huh? That page describes a public appointment process. Where did this happen? Why have I not heard anything about it?

Any response to this? The similar email to wikitech-l is also left unanswered.

In T293323#7430328, @CCicalese_WMF wrote:

[...] Members of the MediaWiki Stakeholders' Group plan to participate in the upcoming MediaWiki 1.37 release in order to gather enough information to generate a detailed task list with assignment of responsibilities that would form the basis of a Memorandum of Understanding.

Did this happen?

In T293323#7686127, @Zabe wrote:

In T293323#7430328, @CCicalese_WMF wrote:

[...] Members of the MediaWiki Stakeholders' Group plan to participate in the upcoming MediaWiki 1.37 release in order to gather enough information to generate a detailed task list with assignment of responsibilities that would form the basis of a Memorandum of Understanding.

Did this happen?

We did participate in the 1.37 release. We are working on documentation now.

Can someone please explain what's happening here and what the current status is? There are tickets like T302160: Grant Access to releasers-mediawiki for MarkAHershberger and Mglaser being filed now which makes it seem like this has been decided, but there's been no update here, nor do I think feedback here was satisfactorily addressed.

A team consisting of the Wikimedia Foundation staff that has been producing recent MediaWiki releases and members of the MediaWiki Stakeholders' Group has been meeting biweekly to work through the details of what would be required to transition the releases. A memorandum of understanding (for lack of a better name for the document) is being drafted that documents these details and what responsibilities would be shifted to the MediaWiki Stakeholders' Group (e.g. generating the release files, tracking blockers, and announcing the releases) and what responsibilities would be retained by the Wikimedia Foundation (e.g. providing the infrastructure for releases and certain details of security releases). As Mark mentioned, members of the MediaWiki Stakeholders' Group (specifically, Mark and Markus) assisted in the preparation of the MediaWiki 1.37 release. To make sure no details are being missed, it was decided by the group that Mark and Markus would take the lead in preparing the MediaWiki 1.38 release, with the assistance of the Wikimedia Foundation staff, flipping the responsibilities from the 1.37 release.

In T293323#7524196, @Legoktm wrote:

If MWStake wants to contribute more to releases, that's fantastic, really. Please, just start helping :) ...and then we can empower more people to do more advanced work that requires specific permissions or roles.

They have been. It has been going well. They need specific permissions to move on the the next step in helping.

Most MWStake members are not MediaWiki *core* developers AFAICT - what is the plan for getting those blockers fixed when they inevitably arise?

The release team is responsible for tracking blockers. The developers of the blocking code are responsible for fixing them. There needs to be effective communication and cooperation between those parties to ensure that blockers are resolved. This collaboration will continue.

Let's talk about effective communication and cooperation. the wikitech-l question about technical decision forum and volunteer roles has not been answered for three months now. I even tried public and private pings but nothing. This is simply not acceptable.

I do agree completely that question should be answered. That is a question for the Technical Decision Forum. This task represents a Problem Statement submitted to the Technical Decision Forum about managing MediaWiki releases. It is unrelated to the role of volunteers on the Technical Decision Forum.

In T293323#7725531, @CCicalese_WMF wrote:

To make sure no details are being missed, it was decided by the group that Mark and Markus would take the lead in preparing the MediaWiki 1.38 release, with the assistance of the Wikimedia Foundation staff, flipping the responsibilities from the 1.37 release.

What about security releases?

In T293323#7725858, @CCicalese_WMF wrote:

I do agree completely that question should be answered. That is a question for the Technical Decision Forum. This task represents a Problem Statement submitted to the Technical Decision Forum about managing MediaWiki releases. It is unrelated to the role of volunteers on the Technical Decision Forum.

As Amir points out, there has literally been no transparency here, from the people working on this and/or the TDF. You are now telling us that there's a group of people who have been meeting regularly to discuss this, except this has (AFAIK) never been mentioned publicly until now, nor has anyone else been invited to join this group. Who are these people? Where can I read the meeting minutes? Where were the calls for participation? As evidenced by this ticket, there are plenty of people who care about MediaWiki releases and making them better, and yet we have all been shut out of this. I don't know whether this is an issue with the TDF or this specific instance of the process, but I do know this is absolutely not how MediaWiki development should work and is not how it's worked in the past.

In T293323#7524196, @Legoktm wrote:

If MWStake wants to contribute more to releases, that's fantastic, really. Please, just start helping :) ...and then we can empower more people to do more advanced work that requires specific permissions or roles.

They have been. It has been going well. They need specific permissions to move on the the next step in helping.

What exactly are the steps here? I do not believe that the act of signing a release and uploading it to releases.wikimedia.org is the next step in helping. That seems like one of the *last* steps.

Most MWStake members are not MediaWiki *core* developers AFAICT - what is the plan for getting those blockers fixed when they inevitably arise?

The release team is responsible for tracking blockers. The developers of the blocking code are responsible for fixing them. There needs to be effective communication and cooperation between those parties to ensure that blockers are resolved. This collaboration will continue.

And what happens when CI starts failing during the release or there's a regression? This sounds really nice in theory, but has not been my experience in reality. I don't understand how we expect people who don't actively contribute to MediaWiki core to do these releases at a high quality level.

I've spent a few more days thinking about this and part of the bad taste in my mouth is that this feels like predetermined solution and this is simply trying to justify that. We haven't really had any discussion about alternative models, nor real consensus on the values that we want out of MediaWiki releases. For me personally, stability and security is the number 1 priority, whereas I don't care as much about timelines slipping if it's in support of that. I also recognize that some people do care a lot about keeping on schedule!

In an effort to be constructive and push the discussion forward I will post a strawman proposal in a few days to create a "MediaWiki release team" that is open to anyone, fully transparent and will hopefully empower more people to contribute to stable releases. The team will focus more on processes and opportunities rather than specific individuals to ensure it's future proof. It will be shaped by my experiences observing the Debian and Fedora release teams, as well as what we do in SecureDrop.

In T293323#7727004, @Legoktm wrote:

In T293323#7725858, @CCicalese_WMF wrote:

In T293323#7524196, @Legoktm wrote:

If MWStake wants to contribute more to releases, that's fantastic, really. Please, just start helping :) ...and then we can empower more people to do more advanced work that requires specific permissions or roles.

They have been. It has been going well. They need specific permissions to move on the the next step in helping.

What exactly are the steps here? I do not believe that the act of signing a release and uploading it to releases.wikimedia.org is the next step in helping. That seems like one of the *last* steps.

Indeed. The rough steps are:

• Started discussing how they could help.
• Kept helping, e.g. test-driving https://www.mediawiki.org/wiki/Release_checklist when I updated it back in April/May.
• Observed the release process and assisted.
• Take over responsibilities from people doing it in their volunteer time.

We are at the last bullet. Clearly you think we're at the first bullet, hence the confusion.

This CTO authority change, having stalled for a year, and belatedly changing into a TDMP request after personnel changes, doesn't really reflect the reality, which is this has been an area starved of volunteers for many years, and causing burn-out and failing because of it. I'd be delighted to discuss further ways we can adjust the process, of course; a proposal to involve more than three volunteers sounds brilliant, if a decade too late.

In response to @Ladsgroup, sometime last year, I saw they were asking people to self-nominate and I did so. Later I was told that I was admitted to the TDF.

That is the sum of my experience of the process.

This is totally not Mark's fault, as he applied to be a community representative well before the idea of transitioning release management off the WMF has come up, and given his work with the MW Stakeholders group he is a natural choice; but I have to say that having a decisionmaking process where the community is represented by the person whose business opportunity the decision is about is not a great look.

In T293323#7733612, @Tgr wrote:

This is totally not Mark's fault, as he applied to be a community representative well before the idea of transitioning release management off the WMF has come up, and given his work with the MW Stakeholders group he is a natural choice; but I have to say that having a decisionmaking process where the community is represented by the person whose business opportunity the decision is about is not a great look.

Not his fault for sure but the process for community appointment is not followed. See https://www.mediawiki.org/wiki/Technical_decision_making/Community_representation#Appointment_process

In T293323#7734667, @Ladsgroup wrote:

Not his fault for sure but the process for community appointment is not followed. See https://www.mediawiki.org/wiki/Technical_decision_making/Community_representation#Appointment_process

Please open a new ticket to discuss the issues surrounding the community appointment process. This task is to discuss the TDF proposal. Process issues deserve their own dedicated task.

The process of producing MediaWiki third party releases is not a highly resourced project within the Wikimedia Foundation. Much of the effort relies on a group of dedicated staff who do so outside the scope of their normal duties because of their personal commitment. As stated in T293323#7733144, "this has been an area starved of volunteers for many years, and causing burn-out and failing because of it".
The MediaWiki Stakeholders' Group recently incorporated as a non-profit and has been deciding what projects to pursue to benefit the third party MediaWiki community. This seemed like an excellent opportunity for one dedicated group of volunteers to help another dedicated group of volunteers. The idea was that the MediaWiki Stakeholders' Group would take releases on as a service to the MediaWiki third party community -- not as a paid contractor to the Wikimedia Foundation.
I wrote an initial draft of a plan to make this happen that I shared with those two groups of volunteers. I am fortunate to be part of both of those groups. Once I determined that both groups were generally supportive of this approach, as demonstrated through activities during the MediaWiki 1.37 release, I took excerpts from that plan to create this Problem Statement in order to share the idea more broadly and get input. I did already have an approach in mind, albeit a skeletal one that still needed many details fleshed out, and that definitely showed through in this Problem Statement.
This plan was an attempt to take advantage of an opportunity, NOT an effort to exclude any other volunteers. It was NOT intended to lack transparency, but it also didn't focus initially on extensive outreach. That was not the goal of the project.
It is good that this discussion has illuminated that there are other volunteers who have an interest in participating in the release process. This project is still in the "research and prototyping" phase (although it had been moved to the decision record phase, that was premature, as we are still trying to discover and document details of the release process and the related responsibilities), and finding a way to broaden it to other volunteers would be most welcome. @Legoktm, I look forward to seeing your plan, especially as it pertains to resourcing. Pragmatically, what I would like to see is a plan that is implementable and will help relieve the burdens of the current volunteers in the near term. I'm also happy to add anybody who is willing to roll up their sleeves and help with the MediaWIki 1.38 release to our bi-weekly planning meetings.
The MediaWiki Stakeholders' Group will happily step back from this project if there is another group willing to take on MediaWiki releases. They have been willing to help lead the upcoming MediaWiki 1.38 release process, which is why they have requested some additional access, so it would be good if a decision could be made affecting their ability to do so soon. If a decision is made to go another way, that is absolutely fine, as long as it helps relieve the burdens of the current volunteers to the release process.

@Jenlenfantwright Hi, this task was moved from Decision Record to Research and Prototyping three days ago and there is no update on it since then. What prompt it to move forward to "Decision Record" again?

Reverting since I didn't get any response.

Based upon the discussion on this ticket, the team that has been working on releases has decided to pause and conduct the MediaWiki 1.38 release in the same manner as the MediaWiki 1.37 release, with the MediaWiki Stakeholders' Group assisting Wikimedia Foundation staff. The original plan had been to swap roles and have the MediaWiki Stakeholders' Group take the lead on the MediaWiki 1.38 release with the assistance of Wikimedia Foundation staff, working towards an eventual transition. We hope this will give sufficient time for @Legoktm or others with an interest to submit alternative plans for discussion here. It is hoped that there could be an alternative approach in place for the MediaWiki 1.39 release to relieve the burden of those currently working on MediaWiki releases.

@Jenlenfantwright: Could you please answer? Thanks.

In T293323#7772053, @Aklapper wrote:

@Jenlenfantwright: Could you please answer? Thanks.

Ping.

This question has not been answered for six months now: https://lists.wikimedia.org/hyperkitty/list/wikitech-l@lists.wikimedia.org/thread/PXXLDIN3AB7G3WDW6Y6JJLTTN7YQI6A7/

While I definitely agree that the question of volunteer members on the Technical Decision Forum is an important one, I will reiterate that this task is not the place to have that discussion, and a new ticket should be opened as @MarkAHershberger suggested above.

What I am eagerly awaiting on this task is further input on viable alternatives for producing MediaWiki releases. The MediaWiki 1.38 release is currently being produced by Wikimedia Foundation staff with support from members of the MediaWiki Stakeholders' Group. What approach should be taken for the MediaWiki 1.39 release?

In T293323#7909539, @CCicalese_WMF wrote:

While I definitely agree that the question of volunteer members on the Technical Decision Forum is an important one, I will reiterate that this task is not the place to have that discussion, and a new ticket should be opened as @MarkAHershberger suggested above.

I apologize for pinging here, I honestly could not find a place to make the question as I already tried email, telling my manager, slack, ping in phabricator and I haven't got anything yet. I will make a ticket.

What I am eagerly awaiting on this task is further input on viable alternatives for producing MediaWiki releases. The MediaWiki 1.38 release is currently being produced by Wikimedia Foundation staff with support from members of the MediaWiki Stakeholders' Group. What approach should be taken for the MediaWiki 1.39 release?

@Legoktm brought a counter-proposal of an open transparent "mw release group". I like that idea a lot. Maybe he should hash it out but in general, I think it's a good idea.

In T293323#7909615, @Ladsgroup wrote:

I apologize for pinging here, I honestly could not find a place to make the question as I already tried email, telling my manager, slack, ping in phabricator and I haven't got anything yet. I will make a ticket.

Thank you!

@Legoktm brought a counter-proposal of an open transparent "mw release group". I like that idea a lot. Maybe he should hash it out but in general, I think it's a good idea.

I would love more information on that suggestion. How would it work? Who would participate? Who would lead it? How would sufficient energy be generated to sustain the process?

The plan is for there to be a document that will lay out the responsibilities for releases, and WMF will retain some of those responsibilities, such as providing the infrastructure and accounts.

Did this document ever get written/published. I think clarifying what is actually being proposed here would help matters. I think the lack of clarity is driving fear, uncertainty and doubt for this proposal.

i think there are a couple of concerns here that are driving resistance to this proposal, which are in people's minds, but haven't been spoken out loud. In the interest of putting cards on the table, I'm just going to bluntly throw them out there.

• MWStake has had minimal involvement with the MediaWiki core developer community. I appreciate many of the people involved are MW consultants, sysadmins of major MediaWiki installs, or at least write and maintain their own extensions and thus are quite familiar with the product. Nonetheless, the lack of involvement in the development of mediawiki core is concerning. Will they be able to properly test and assess tricky regressions? Will they be able to effectively communicate with WMF teams if those teams are "blocking" the release in some way?
  • Perhaps that's not included in the part that is being taken over by MWStake? If not that, then what are they doing? Running tar every couple months? If that's all, why even bother with all this? Is this the sort of situation where MWStake plans to basically do the easy step and take credit for the whole process?
• What if anything is MWStake intending to change about the review process. There is the implication that they would be able to better serve the third party communities than WMF can, but its very unclear why this would be so, and what they would do differently. If changes are made, will stakeholders (i.e. non MWStake stakeholders) have opportunity to be consulted?
• What happens if MWStake does a terrible job, will it revert back to WMF? WMF does a decent job and is a known quantity. MWStake is unknown.
• MW releases were outsourced previously. This was stopped due to too much overhead ( https://lists.wikimedia.org/hyperkitty/list/wikitech-l@lists.wikimedia.org/thread/HQIQNJWHDCONFIJ32X7O3QW7PTNXWORH/ ). Why won't the same thing happen again? Have lessons been learned, or approaches changed so that this won't be an issue?
• The big one: MWStake wants to fundraise by attracting donations & memberships from corporate users of MediaWiki. To do this, they need to gain legitimacy in the eyes of their potential donors. To me it appears that being able to say that they are responsible for MediaWiki's public releases would go a long way to this goal and thus financial motivations are involved. T293323#7475610 essentially says as much.
  • While I don't think anything is inherently wrong with that, we do have to make sure that we are doing this transition because it will be good for MediaWiki, and not just good for the MWStake group. In particular, where financial benefit is involved, we should be extra transparent and especially mindful of conflicts of interest.

In conclusion, I don't think I have any objections to MWStake helping with releases, if they are willing, and the existent participants in the release process are willing. Additionally, I feel we should not cookie lick preventing them from doing so until some other group that doesn't exist yet forms. I think to many (at least to me), the sticking point is the "official-ness" of this move. What authority is being delegated and how will that impact both developers and users of the release? How does MWStake plan to leverage this new position for their own ends, and will it be reasonable? Will there be an opportunity for the community at large to provide feedback after some time period to asses if they are doing a good job?

I wrote up a proposal back in March and never posted it because my IRL life got a bit crazy with moving, sorry about that.

Anyways, my idea was to have a MediaWiki release team, that would be responsible for this process.

• Membership would be open to anyone (sign up on a wiki page), but people who don't participate for 1 stable release process are removed (and can freely rejoin whenever active again). Membership gives no special permissions (aside from getting a vote in meetings), rather it provides a venue for people to demonstrate their skill/demeanor/etc. that they would be a good candidate for +2, release perms, whatever.
• Each release version (1.37, 1.38, etc.) has a "release manager" (RM) and a "deputy release manager" (DRM). The release manager is expected to serve in that role for the entirety of the support period for that version, though the responsibility is expected to decrease as the version gets older. The team will select RM/DRMs at the beginning of the release cycle, based on who volunteers (and if people don't do a good job, the team can replace them).
• After a branch cut, the team meets weekly in a public IRC/Matrix channel (or say Jitsi if A/V is desired), reviewing bugs tagged as blockers, and if it's not obviously clear, majority voting if they should be a blocker or not. (Ideally the designated RM/DRM would have reviewed the bugs ahead of time to provide guidance to the rest of the team so the whole meeting isn't just people reading bugs for the first time). Finally, the team decides whether to issue a new RC, wait, or go ahead and do the stable release. It might also make sense for the team to periodically meet during the development cycle, just to prod blockers along and work on tooling or process improvements.
• The RM/DRM are expected to regularly review master's git log, opportunistically backporting patches when possible. (And hopefully can use tools like https://www.mediawiki.org/wiki/User:Legoktm/pickme to help with that). This is not an exclusive responsibility, as other developers who already are backporting stuff should be encouraged to continue (and thanked for doing so!), but this gives a point of contact to cc if you're unsure or don't have +2 rights.

Goals:

• Foster a healthy mix of responsibility (being a RM/DRM) to empower people, while allowing people to contribute regardless of how heavily involved they are: anyone can join open meetings, and regulars get a vote.
• Build in a natural system of succession and knowledge sharing by having a DRM shadow/assist the RM (or the other way around!), and also (hopefully, if enough people are interested) regularly rotating the RM/DRM positions so more people can do it.
• Transparency.
• At worst, be no worse than the status quo/what is proposed here. Like, if we create a MediaWiki release team and no one ends up joining besides MWStake members, then it'll just be those people determining on blockers, serving as RM/DRM, which AIUI is what was desired. BUT, it won't be exclusively MWStake members, and the door will always be open for anyone else to join and participate.
  • And the status quo is that Reedy is the RM, and also the DRM, and gets support from people on an ad-hoc basis who would presumably be team members. So at least we'll be a little better than that.

I don't think this is perfect, but I hope it's a decent framework that can be tweaked as things go along (e.g. if the team wants to designate a chair to help with facilitation). None of this is novel at all, it's parts borrowed from Debian, Fedora, PHP and SecureDrop.

@Legoktm would than happen on a fully volunteer basis? If not, who would handle the money and HR responsibilities?

In T293323#7960801, @Tgr wrote:

@Legoktm would than happen on a fully volunteer basis? If not, who would handle the money and HR responsibilities?

I'm not sure HR and money responsibilities would be needed here but a tweak to the proposal could be that WMF would appoint a couple of seats there and the rest would go to the volunteer group (that can be from the stakeholders group, other volunteers, staff in their volunteer capacity, etc.)