Courtesy CC to @Xaosflux, who applied the tag on a feature task earlier today.

Note that prior to @Frostly 2023 changes, the tag was limited to configuration changes even more explicitly. It read:

Local on-wiki community consensus is needed for a configuration variable or setting change, to confirm that the request is supported by the community. This tag is set when no link to such a discussion/decision has been provided.

Rather than only naming configuration/setting changes as examples, it used to name those two changes as the only cases in which the tag is applicable.

While ideally developers wouldn't deploy anything community impacting that is contentious having a way to identify that the impact of a request would benefit from community discussion doesn't seem like a bad thing.

Hi @Urbanecm, thanks for creating this task. I added the last sentence to the tag description as I noticed that the tag was being used for major changes that weren’t configuration changes. I completely agree that community consensus is not necessarily needed just because someone objects, but I also think that there are many relevant times when community consensus is legitimately needed for major changes to core or extension functionality.

Perhaps the tag could be split to two versions, for configuration changes and not? I’m also open to workshopping and wordsmithing the description to make it clear the types of (non-configuration) changes that would be applicable.

There were 29 tasks in Community-consensus-needed not also in Wikimedia-Site-requests: https://phabricator.wikimedia.org/project/board/175/?filter=u3MDzS2JJ0Lj. 5 of them were really requests for configuration changes but missing the tag so I added it: T260286, T117958, T138711, T271001, T85847

And I removed the tag from T140069, T170696 , and T51979 because I don't think they need community consensus at all.

However, I disagree with the premise here entirely - the usage of the Community-consensus-needed tag means someone thinks the feature request needs a community discussion. That's different from personally disagreeing with it - I disagree with a lot of proposed features that I know are in the authority of the developers to implement or not, and usually express that with a token rather than with any tags.

The remaining ticket in that category are hybrid, including both "build a feature" and implicitly "implement that feature on Wikimedia wikis", where the latter is a valid subject of disagreement. And I think the tag can capture that just fine. So I disagree with the idea here entirely.

In T380763#10354286, @Pppery wrote:

However, I disagree with the premise here entirely - the usage of the Community-consensus-needed tag means someone thinks the feature request needs a community discussion. That's different from personally disagreeing with it - I disagree with a lot of proposed features that I know are in the authority of the developers to implement or not, and usually express that with a token rather than with any tags.

My problem with the current system is that it is unpredictable. What kind of changes should have consensus demonstrated preemptively (besides config changes)? Without that question having a clear answer, the tag would be – in practice – applied when someone disagrees with the proposal. If we can define when consensus is always needed and when not, I don't have any issue with expanding the tag's purpose.

The remaining ticket in that category are hybrid, including both "build a feature" and implicitly "implement that feature on Wikimedia wikis", where the latter is a valid subject of disagreement. And I think the tag can capture that just fine.

I believe those cases should be split to an implementation task and a deployment task. That way, the consensus tag can still keep a well defined purpose while being useful for the changes you suggest.

In T380763#10354217, @Frostly wrote:

I completely agree that community consensus is not necessarily needed just because someone objects, but I also think that there are many relevant times when community consensus is legitimately needed for major changes to core or extension functionality.

Would it be possible to name some examples? In my experience, while a lot of the major changes require consensus of the technical community, it is very rare those changes also need consensus of the users. In all cases I'm aware of, the users' consensus is important for _deploying_ a feature, not creating it, which are two different things.

Perhaps the tag could be split to two versions, for configuration changes and not?

As I mentioned in the description, creating a secondary tag was discussed in the past and ultimately declined. If you think the circumstances changed, feel free to re-propose that change.

This is really an engineering management problem, not a project management problem. WMF engineering management processes should prevent software changes that may be controversial from happening without involving the impacted users. The WMF, historically, has been somewhere between inconsistent and bad at this. Sometimes negative comments left by volunteers on tasks are simply ignored, which has resulted in Community-consensus-needed being used to give those comments higher visibility. The correct solution here is an effective engineering decision making process, but fixing that is out of scope for this task.

Since the WMF has often taken the position that not deploying features they have developed is an irresponsible use of donor money, I do not see a meaningful distinction between developing a feature and deploying it in the broad case.

I believe those cases should be split to an implementation task and a deployment task. That way, the consensus tag can still keep a well defined purpose while being useful for the changes you suggest.

Many of them are in components like Move-Files-To-Commons or Wikidata-Query-Service where the only user is Wikimedia, hence deploying and building the feature are one and the same.