Talk:Technical Collaboration Guidance/Community decisions

According to the Collaboration Guideline, the project team may decline any Community Consensus blocker they dislike.

If there is a Community Consensus that something is harmful to the encyclopedia and our mission, the community routinely uses various tools to block, change, override, or otherwise address the source of the problem. For purposes of this discussion, let us consider a multi-wiki Community Consensus representing a majority of the global editing community. (i.e. a Global Community Consensus.)

Clarification is needed on the next step, if the team declines a Global Community Consensus blocker, proceeds with deployment, and the community disabled/overrides/changes_default in a Good Faith effort to protect and preserve our mission.

There are basically two options:

1. If the WMF's next step is either acceptance or discussion of the issue with the community, then the guideline should to say a Blocker supported by Global Community Consensus is by definition as a critical issue. It needs to say a Global Community Consensus Blocker by definition goes to discuss rather than decline.
2. The alternative next step is to impose enforcement on block-declines. Either redeploying Superprotect, or returning to threats of at-will revocation against any Admin who follows consensus, or equivalent battleground-by-force tactics.

I am seriously scared of a potential repeat of #2. I am afraid a repeat could escalate into community consensus for something like {{RFC}} SOPAWMF. If that seven-letter RFC ever gets consensus then we're all screwed.

One way or the other, clarification is needed on the next step in the Collaboration Guideline. The last thing we want is to ignore that question until everyone is already in the middle of a stressful disagreement.

Yes, a recommendation for next steps in case of disagreement is needed. I propose to get the current draft about community decisions through one review, to assure that we agree on the regular process. Once the basics are agreed, then we will be in a better position to agree on the specific situation of a disagreement and its escalation path.

Whether or not the project team may disregard consensus here is a very important point. If the community is the one that actually decides whether something is a blocker, then it would be very important to make that completely clear, in order to reduce initial hostilities. These kinds of battles aren't fun, and don't result in helpful collaborative discussion and feedback.

@Yair rand the page flat out states the project team may disregard consensus.

I don't see much likelihood that the the WMF is about to reverse position. I see even less likelihood the community will have any respect for this page/process. In fact I expect this page will only inflame any dispute, if and when the WMF ever tries to cite it.

> "...the community will be asked for a new review. If no surprises are found, the deployment will proceed."

I wonder whether this "new review" is intended to be limited to reviewing whether the accepted blocker was solved, or if it is meant to be a completely new review. There are circumstances in which either option would be the most appropriate, but I'm concerned that in the currently written form, it is almost asking community members to propose blockers (and getting them accepted and fixed), reviewing again, moving the goalposts, and repeating the cycle endlessly.

AFAIK the "new review" is for the previously identified blockers, otherwise there is the potential for an endless "review loop" as you mention.

If a software development project got stuck in a cycle of trying to fix a product, which customers declined to buy after each iteration, what would be the expected private sector outcome?

If you're a startup, you might consider pivoting. If you're developing enterprise, you'd consider finding and selling to a new client base.

None of these options matters if you're developing open source software for a non-profit, though. Comparisons to business-based solutions are not generally appropriate, as there is no profit motive.

To clarify: the goal of the software development at the WMF is to better serve the mission. That is the lens through which products are built, and the motivation behind them. This is a completely different motivation than that which serves the private sector, and the two simply cannot be compared because decisions are made differently in that context.

You're making a dangerous error suggesting that non-profit status somehow makes the WMF immune to external reality.

A product is always built with an original belief that it will be desired and valuable. Whether an organization is commercial or non-profit makes no difference. But no person or organization is perfect or omniscient. Sometimes a product is simply a flop. If a product has content-corruption issues as a fundamental design flaw, or unacceptably bad performance issues as a fundamental design flaw, or if the design-team simply misjudged what end-users want and need in a product, a reasonably run company terminates the project and stops wasting additional money on it. If a company stubbornly persists in a product that users don't want, reality eventually punishes that irrational behavior. Money stops coming in, and the mangers, developers, and support staff stop getting paychecks.

The WMF has the luxury of being a charitable organization hosting a website with enormous public good-will (Wikipedia). It has the luxury that there is a disconnect between donors and the actual users of the products. The WMF has significant, but not boundless luxury to waste extensive money developing and pushing a faulty or unwanted design. The WMF has a significant buffer of being able to continue receiving donations while the end-users are the only ones who know the product(s) are faulty or unwanted. However it is a serious error to think that the WMF is somehow immune from the same reality as commercial development projects. If the end users become sufficiently dissatisfied with the product(s), they may inform donors of the situation. At that point the exact same reality applies. Money stops coming in, and the managers, developers, and support staff involved stop getting paychecks. That would be bad. The WMF should operate in a reasonable and rational manner. Good intentions for a product don't matter if real world feedback on a defective or unwanted product is being ignored.

Can we at least agree that the WMF should stop sinking money into a project when there is no dispute that it is overwhelmingly unwanted, AND it has fundamental design flaws that result in content corruption?

The Wikimedia Foundation has removed tools and services that it did not believe were delivering on their goals. Some of them, such as AFT5, were valuable to one type of user, and popular on some projects (e.g., the French Wikipedia, in the case of AFT5), but created burdens on others (oversighters at the English Wikipedia, in the case of AFT5). Others didn't really work out the way they were planned (such as MoodBar, which did not achieve its objectives and so was undeployed rather than taking up experienced editors' time, frustrating new editors, and distracting development from priorities).

In other cases, tools aren't developed enough to be evaluated fairly, or they appeal to only certain groups. If we used the visual editor as an example, a few experienced editors on some wikis still believe that it's undesirable to make this editing environment available to anyone.

However, from another perspective, we'd have to account for these facts:

• As of last quarter, at least 30% of all editors use the visual editor.
• Some new editors with an educational focus, such as librarians and GLAM institutions, have previously refused to edit Wikipedia because they did not want to spend the time necessary to learn wikitext, and they are now using the visual editor exclusively.
• Chapters and other organisations training new Wikipedia editors very frequently comment on how the visual editing mode is crucial in making those experiences a success.
• VisualEditor is the most popular extension to MediaWiki, and it and the underlying rich editor software is being used at many other organizations, including NASA and other institutions that undertake educational work parallel to our own.

I suspect that facts such as these might cause unbiased people to conclude that this software is a desirable project. From the product perspective, although this software prompts some debate among some highly experienced editors, it is generally helpful to and primarily used by people with less experience, whose views and needs the team must also take into consideration.

P.S. You might be interested in my suggestion for research about whether new editors who use the visual editor are less likely to produce speedy-deletion-worthy pages under ORES's draftquality measurement, compared to new editors who use the older wikitext editors. I've been looking at the behavior of some new accounts, and I think it might be a significant predictor of success.

I wasn't referring to VisualEditor. The original VisualEditor RFC consensus was "1. VisualEditor is a good idea in theory": there is clear support for this, most people agree that a Visual Editor is in itself a good idea. The WMF then listened to community concerns, and the WMF successfully improved it such that the community agreed that deployment was beneficial. So the VisualEditor example is, if anything, supportive of my point.

Your initial topic was what should happen after the community filed blockers and the WMF did work trying to improve the product. One option was that that the community may still say there are issues that block deployment. The other option was that the WMF declares the community gets one opportunity to identify problems, the WMF then makes one effort to address those problems, then the WMF terminates engagement and forces out the product.

None of us desire a case where resources are wasted on an "endless cycle" of improvement and rejection. The question is whether we should break such a cycle by terminating such a project as early as possible? (My answer.) Or do we terminate the cycle by terminating engagement and forcing out the product? (The effective result implied by Keegan's response.)

I'm horrified, but not surprised, that we're even discussing this.

I think it is difficult for most end users to accurately determine which projects constituted "wasted resources", and which are worth further investments, especially when the product is in early development. That determination can be difficult even for highly experienced, well-informed people with analytics resources and hundreds of hours to devote to studying the question.

I also want to repeat what's becoming a constant theme: There is more than one community. For example, the German Wikipedia and Commons explicitly encourage a type of username that the English Wikipedia bans. It doesn't make sense to talk about what "the community" wants, as if there were only one community, or as if those communities were always adequately represented by the individuals who happen to participate in any given discussion.

I also want to repeat what's becoming a constant theme: There is more than one community.

I also want to repeat what's becoming a constant theme: If wikis representing a majority of the global community reach consensus on a blocker, that needs to constitute a per se blocker that goes to "discuss" rather than "decline".

So until you and the WMF acknowledge Global Community Consensus, I request that you stop making disingenuous appeals to a lack of Global Community Consensus.

We could probably have a nice philosophical discussion about whether a global community even exists, but it's kind of off topic. What's relevant here is that the TCG says that only the product manager can decide that a problem blocks deployment. That means not "the WMF", and not "the Global Community Consensus", and not anybody else.

I concur that the current text of the TCG contains words saying that the product manager can decide whether a problem blocks deployment.

However, as Qgil has acknowledged in previous discussions about the TCG, that is where processes within the TCG end. The TCG is advice for staff, on best practices for inviting community involvement. The post-TCG process is then likely to proceed with the community taking action which has the actual effect of blocking deployment.

Your move.

I'm having difficulties following the points being discussed here, but since I have been mentioned...  :) The TCG aims to cover the entire software development process, from beginning to end. It also aims to document best practices both for development teams and communities.

"The community taking action" and "blocking deployment" are expressions semantically charged, but I wonder what they mean in practice. Technically speaking, Wikimedia communities may reach consensus on specific topics. Deployments can be pushed or blocked by the people who have the corresponding permissions. In some circumstances, wiki administrators or other users might find ways to boycott a deployment. However, there is no single or simple connection between "community taking action" and "blocking deployment". Just like there is no single or simple connection between i.e. "Wikimedia Foundation proceeding with plans" and "ignoring communities". What we have are different cogs either collaborating efficiently, disconnected, or spinning against each other.

I would have to work to find the link, but you and I were discussing what happens after the WMF declines a blocker. You explicitly acknowledged that the community may respond by following through on consensus. Setting aside semantic trivia whether something "blocks deployment", we are discussing action which has the practical effect of reversing the problem, blocking the problem, disabling the problem, or otherwise attempting to improve the configuration and functioning of the wiki. (Which, from the WMF's point of view, nullifies the intended deployment.)

You said that is outside of the TCG. You said the WMF would not respond with Superprotect or any similar methods. Your approximate words were that we would turn to the "normal wiki dispute resolution process". I was unable to get clarification whether the WMF's view of "normal wiki dispute resolution process" was compatible with the community's understanding of "normal wiki dispute resolution process".

If you want concrete examples, I'll give two.

The WMF gave explicit assurances that VE would not be made the default editor without asking the community first. VE was then set as the default editor. The WMF was completely non-responsive on the issue for almost two weeks. When I escalated the issue to the Executive Director, we were then told it would be reversed. After weeks of inaction, the WMF then stated it would not be changed. The EnWiki community wrote a patch for the sitewide javascript that would override the WMF's setting.

The javascript was never deployed. The WMF did change the default. The discussion here is what would happen if the WMF had declined to roll back the VE-default? What would happen if the community did deploy the javascript?

Second example. The EnWiki community currently has a standing consensus against the NewWikitextEditor. For several months, I have been attempting to get a constructive response from the WMF on how it intends to resolve this situation. The project manager is completely non-responsive, and the liaison is unwilling or unable to constructively address the situation. Time is up on this. I have pretty much decided to just open a second RFC on the NewWikitextEditor. The three RFC options are:

1. Withdraw the previous-RFC blockers. (Extremely unlikely)
2. Reassert the block, assert that the NewWikitextEditor not be deployed to opt-out without a new consensus to do so, and take no concrete action. (Possible)
3. Reassert the block, ask the WMF to roll back the NewWikitextEditor beta, and if necessary take action to do so ourselves. This would involve an editfilter informing users of the planned removal from beta features, possibly followed by an editfilter or javascript block of the NewEditor itself. (Possible)

Yes, that last option is very very ugly. However I literally posted an image of a big red flag warning that we were heading to a potential hot-conflict. The WMF was explicitly warned about that last option. The WMF has been ignoring the situation.

Qgil, when I tried to have an abstract discussion with you this kind of problem, your response was basically that the TCG is so awesome and the WMF will be so collaborative that we're never going to have this problem anymore. Well, here it is.

When I first saw your TGC page with the metaphor-images of the friendly boat visiting ports, my instant reaction was to go to commons and replace the images with a more obvious metaphor. I found a rather impressive series of a train crashing through warnings and barriers, barreling straight at the community, and running us over. The unstoppable train metaphor. I didn't save the edit. This project is the unstoppable train.

For a year, the WMF has known there was a serious problem here. I tried appealing to your TCG, giving the WMG exactly the sort of Actionable Blockers the WMF asked for, with exactly the process and language the WMF wanted. The WMF ignored it. The WMF has no plans for constructively resolving this conflict. The WMF is just driving the train forwards. Whoever is driving the train is either asleep at the wheel, or they explicitly plan to drive this train over the community on deployment day.

I believe we agreed that the last thing we want is for a project to blow up on deployment day. Well, if we have to find out what the "post-TCG-process" looks like, we may as well do it now. What happens if the community says YES, we really are putting up a blocker on the NewWikitextEditor? What happens if the community shuts down the NewWiktextEditor beta?

Yes, I remember that conversation and I haven't changed my mind. I keep thinking that the answer to your "what would happen if..." questions is "normal wiki dispute resolution process", simply meaning whatever dispute resolutions processes exist in our movement for the problem at hand.

Maybe it is a matter of perspective, but it has been a while that I am not seeing trains crashing. Not even the examples you put, the blockers you propose and the many RfCs you start or encourage look to me like trains crashing. We are a very big complex community of communities, having everybody happy always is difficult, knowing what are the right next steps is not always straightforward, and frictions appear from time to time. Still, beyond the small world of Phabricator tasks, RfCs, VillagePumps, specialized Talk pages... there is a big community of volunteers choosing to put their time and creativity in Wikimedia projects, and beyond that there is an even bigger audience of Wikimedia users that trust us, find us useful, and hopefully will come back to us for more. People like you or I discuss in our little corners for the happiness of those volunteers and those users.

From this perspective, I think we are doing fine, and improving.

On the general subject, I think that this is a hard thing to address in policy. On the one hand, there are problems with saying that proposing blockers is a one-time event. To give only one of the obvious cases, what if problem X is identified and fixed, but the "fix" creates an even worse problem? On the other hand, if an individual doesn't want the project (for any reason or no reason), then that editor may be motivated to find an endless list of allegedly critical problems, when the real problem is "I just don't like it" or "This helps other people instead of me" or even "I thought this project was the opposite of what it was".

For large projects, it may make more sense to think of this process as a continuous, overlapping discussion: The proposal, discussion, fix, and review for problem X is completely unrelated to the proposal, discussion, fix, and review for problem Y. But it's less clear how that continuous, overlapping process reaches a single decision point, such as when to move the preferences for a feature out of the Beta Feature tab and into the normal preferences section.

For small projects, a unified proposal/discussion/fix/review process might make a lot of sense.

I don't think that it's useful to fixate on "forcing out the product". That's not actually possible in some cases (e.g., Contributors/Projects/Accessible editing buttons), it is unusual even to have it discussed, and AFAICT it's never been necessary. (For example, in 2013, the English Wikipedia went from starting the formal proposal to hiding the tool in about 18 hours, and it likely would have been unnecessary if they'd just waited until the next day, i.e., when the PM was back in the office.)

On the other hand, if an individual doesn't want the project (for any reason or no reason), then that editor may be motivated to find an endless list of allegedly critical problems

An individual gets squashed by consensus.

I don't think that it's useful to fixate on "forcing out the product".

There would be a lot less focus on that topic if you weren't up to your eyeballs in the issue right now. There would be a lot less focus on that topic if were to acknowledge that there is a standing consensus against the NewWikitext editor on EnWiki, and give an explicit statement that it won't be deployed as the default wikitext editor on EnWiki without community reversal of that consensus. (And any other wiki that may reach a similar consensus.)

An individual doesn't always "get squashed by consensus" at the smaller wikis, or even at poorly attended discussions at the larger wikis. The TCG needs to work for all of the wikis, including the ones that have only a few active participants.

I can solve the 'rogue wiki' problem for you. But you'd have to acknowledge some form or mechanism of Global Community Consensus first.

Action taken

The main page asserts that "The TCG establishes best practices for inviting community involvement in the product development and deployment cycle." So it's important to get them right. Let me quote

The Wikimedia Foundation designs and develops software as part of its mission to provide the essential infrastructure and an organizational framework for the wiki projects. This development must be collaborative and receptive to feedback throughout the life cycle of a product.

Foundation Product teams should share information with the communities about software features considered, as early as possible in the project timeline. The communication of proposals can include goals, plans, early designs and other methods of communication.

I suggest expanding the first statement to

The Wikimedia Foundation works with the wider communities to design and develop software as part of its mission ...

and the second to

Foundation Product teams should collaborate and share information with the communities about software features considered

It may be that these additions were thought to be implicit in the original wording, in which case there can be little harm in making them explicit. It may also be that they are not what was intended, in which case, my response is that they should be.

Done, thank you.

Since communities will not be allowed to file blockers that do not "meet certain quality criteria", one of which is "[d]emonstration of familiarity with the project plan", we must presume that in future all such project will have associated with them a single entity ("the") which we may call a "project plan". This doesn't seem to be quite in the spirit within which WMF interprets the Agile philosophy, but it is music to the ears of those of us who believe the WMF approach to be sometimes less than sufficiently plan-full. As an illustration of how this might work, please point to the entity known as "the project plan" for the 2017 wikitext editor, so that we may familiarise ourselves with it.

> Since communities will not be allowed to file blockers that do not "meet certain quality criteria"

The draft says "blockers aiming to change the course of a software project should meet certain quality criteria". Communities and whoever else can report blockers, and if those blockers miss something initially, they can be improved.

About the project plan, the draft says "Foundation Product teams should share information with the communities about software features considered, as early as possible in the project timeline. The communication of proposals can include goals, plans, early designs and other methods of communication."

In more detail, Technical Collaboration Guideline/Milestone communication#Where defines "a dedicated wiki product or project page" as must-have.

Technical Collaboration Guideline/Milestone communication#Proposals defines several must-have conditions for information about new projects.

What I do not want to see is legitimate blockers being discounted on the grounds that there is some obscure piece of documentation that the the people posing the blocker are not cognisant of. "Familarity with the plan" is already a high bar to meet and if there's no such thing as "the plan" to be familiar with then it's a bar that's going to be logically impossible to get over. If "the plan" refers to the whole range of documentation information and communication, formal and informal, public and private, mature and immature, then it's a bar that's going to be practically impossible to get over.

Agreed, that would not make any sense.

So what's the resolution? If there's not going to be any such thing as "the project plan" (which seems a bad idea to me), how does this sort of conversation get going at all?

The project plan you mention aka "a dedicated wiki product or project page" is considered a must-have, as explained above. If it is missing, then that is a blocker in itself because it impedes anyone but the development team to understand the project and get involved.

Thanks, I think it's important to get these things clarified before they have to be exercised, especially since there are expectations going both ways in these guidelines.

Rogol, I think that the main point behind "familiarity with the project plan" is to note that "blockers" that are irrelevant or demonstrably factually wrong are going to be ignored. If you've spent any time around group discussions, I'm sure you've seen things that run like this:

• Alice: I propose that we save the whales today.
• Bob: I absolutely oppose your proposal. Instead, I demand that we save the whales!
• Chris: Bob's right. We cannot agree to Alice's proposal to save the whales, because we must first save the whales, and we must save them today.
• Passing user: Discussion closed, with consensus against Alice's proposal to save the whales.

In plainer language, this means that if you're trying to block a project, then you need to know what you're talking about at a basic level.

I quite agree that anyone trying to change the course of a project (blocking it being the most extreme example) needs to know about it at some level. I don't think anyone is proposing that these discussions take place on the basis of complete ignorance. What is under discussion is the extent to which familiarity with the entire project plan is required before discussions are allowed to begin. That means that those planning and executing the project need to share their plans and progress with the wider community and engage with them. In the spirit of your parody of an argument let me offer you some other parodies – of course it is inconceivable that anything like that would happen here, either now or in the future.

• (User) I think this proposal will break the formatting of Elbonian accents
• (Dev) Well we haven't published any plans yet so we don't have to listen to you lalala
• [Time passes]
• (User) Elbonian accents don't work any more
• (Dev) Too late, that checkpoint is already past so we don't have to listen to you lalala

or

• (User) This plan does not cover the formatting of Elbonian accents
• (Dev) Have you read document number 473 from the documentation set kept in the filing cabinet marked "Beware of the Leopard'?
• (User) No, I didn't know that existed
• (Dev) If you people can't be bothered to read the documentation we don;t have to listen to you lalala

or

• (User) Elbonian accents don't work any more
• (Dev) We told you that the code wouldn't accept Unicode characters from prime numbered codesets, you should have known that meant Elbonian lalala

I think it's meant to say that you need to be familiar with the part that you're contesting, and being open to changing your mind on the basis of information you receive. Thus "being familiar with" includes learning new things during a discussion. For example:

• User: This plan does not cover the formatting of Elbonian accents.
• Dev: Have you read document number 473 from the documentation set kept in the filing cabinet marked "Beware of the Leopard'?
• User: No, I didn't know that existed. Thanks for the link. [Time passes] Huh, it looks like your plan actually does cover the formatting of Elbonian accents after all.
• Dev: {{resolved}}

Well, now that we've all had our fun, let's return to the issue of what a project plan is and how it can be communicated to, and developed in collaboration with, users. The object is surely to prevent this sort of dialogue from starting, because the plan should be clear. Unfortunately, the WMF interpration of "Agile' seems to stand in the way of this sort of planning: it has been summarised, presumably authoritatively, as "the plan is to create something reasonable, to let interested people try it, and then to adjust based upon their feedback". How can we square this circle?

This guideline is meant to be used in real situations, and I think it is better to check the current draft recommendations against real situations where a blocker is being considered.

Indeed. To return to the point that started this thread, can you point to some examples of "the project plan" with which yu would expect those proposing blockers to be familiar in the case of some existing projects. I suggested the 2017 wikitext editor, which is already controversial; another good candidate is the parser unification project, which is associated with the same controversy.

Of course I realise that this is unfair in the sense that I know already that there is no such object for either of those projects. So how can one file a bocker in either of these cases?

Looking back in time, what would you point to as "the project plan" for Flow? It has a sprawling mass of inconsistent documentation across multiple wikis, has been the subject of multiple attempts to file blockers, and yet it is rather hard to discover from all of that what the overall status of the project is. Again, how can people file blockers against something like this?

• 2017 wikitext editor explains the plan for this project.
• Parsoid is the parser that has the explicit intention to take over all the parsers, and that page offers information about the project.
• Flow is indeed the project page for Flow, and it specifies project status and current plans.

You are proposing a mental exercise of filing a blocker about these projects when the project information is not up to your expectations. I think it is better to look at real situations where a community or an individual wants to file a blocker or has filed it already, and that blocker is flawed because the project information is flawed too.

I am discussing how best to document projects before disagreement arises, since that is a good way to head of those disagreements before they happen. That seems to me a worthy excercise.

I could go on at length about the plans for the projects that you mention, but will confine myself to one. The page Parsoid does not mention that it has an explicit intention to take over all other parsers. That may be so, but to the best of my knowledge it is not yet documented in any place reasonably accessible to the community or reasonably describable as "the project plan" for the parser unification project, and we would not have found out about it if I had not asked you here. That is not a satisfactory project plan: it is quite likely that there will be an attempt to file a blocker, since the concept of storing HTML rather than wikitext is flawed in itself (since HTML cannot represent a huge portion of the world's information), will likely break or be broken by a huge amount of existing wikitext during the conversion of millions of articles in the existing databases, and is contrary to assurances given elsewhere that the database will always be wikitext and will always be editable as such. WMF and users went round this once already over Flow, as you will recall. It also contradicts the blog post, linked to on the page you refer to as part of the plan, that HTML storage will be complementary to wikitext storage. So this is an absolutely vital piece of information which is revealed here for the only time and not available in any "project plan" known to me. Are you sure you have it right?

>  HTML cannot represent a huge portion of the world's information

Do you have an example in mind here?

> contrary to assurances given elsewhere that the database will always be wikitext and will always be editable as such.

Always is a very long time. Would you mind providing a link to any statement that wikitext will endure through the millennia? I've seen (and made) statements about wikitext being available to editors "for the foreseeable future", but I don't ever recall anyone saying that it will endure "always".

HTML is unable to represent information which is not essentially linear alphabetic text. For example: music; Mayan and Egyptian hieorglyphics; Arabic and Chinese cursive scripts and chancery script; three-dimensional genomic and proteomic structures or prints; chemical and mathematical formulae; railway, social or electrical networks; any kind of image; video, audio, VR or gaming streams; the Book of Kells; the trajectories of the asteroid belt; and so on.

Page 2017 wikitext editor states "However, the strategy is not and has never been to replace wikitext"; "The current wikitext editor is not going anywhere, at least for the next few years. While we may eventually sunset it, anyone who likes it can keep it.". At Talk:Wikimedia Product, you said "The database is currently, and for the foreseeable future will continue to be, wikitext. For the foreseeable future, there will continue to be an editor which will allow contributors to directly edit the stored wikitext." If you feel that reporting that as "the database will always be wikitext and will always be editable as such" is inaccurate then I note your point. Please do not attempt to derail a sensible discussion by quibbling about the distinction between the words "always" and "for the foreseeable future".

The point is that the community has a reasonable expectation of being able to invest time and effort into the current way of working without finding the ground suddenly cut from under their feet by an unexpected and unwelcome change, in the planning of which they ought to have been but were not involved. In particular, I am taking it from the assurances that you are giving that there is no planning currently under way within the WMF to replace the content databases currently employing wikitext by, for example, a system based on a parser linked to an underlying database that emplys an HTML/RDFa document model. If that is not the case, we need to know right now.

However, given the topic of this thread, I suppose that the solution is really in your hands. Simply publish the project plans for the parser unification project and the new wikitext editor project, and the roadmaps that they link into, and we can all read for ourselves what the WMF intend to do with these various projects and products, and discuss any potential blockers before time and effort is wasted.

> Are you sure you have it right?

Not at all, sorry. Parsoid / parsers are out of my areas of expertise. I am here to discuss how to improve Technical Collaboration Guideline/Community decisions.

So am I ... It was not I who diverted the conversation by making an apparently authoritative statement about the unified parser project which it now appears you are not at all sure was correct. (In future, please, if you do not know, just say that you do not know.) The result is that you have wasted your time and mine in fruitless speculation about something that may or may not turn out to be correct and if correct may or may not turn out to be a blocker, just like the time that Flow was being designed. That is why there needs to be a clear, actionable project plan that you can point to. Indeed, that's what these guidelines say. So this is a perfect illustration of how things go wrong without a project plan and why a project plan is best practice.

As to why the unified parser project, which is important enough to merit its own line in the annual plan, does not have a published project plan which the community can use, and which would allow the questions that I raise and the blockers that I foreshadow here to be addressed before more time and energy is wasted ... Well you tell me.

Since communities will not be allowed to file blockers that do not "meet certain quality criteria", one of which is "Use of [...] data", it would be helpful to know on whose shoulders the burden of collecting that data lies. Suppose that I, as a volunteer, believe from my own experience that a particular feature is used reasonably often and would be broken by a proposed change. Who is tasked with substantiating this impression? Is that down to me and my fellow volunteers? With what resources? Or would there be some member of the staff, possibly on the development project team, resourced and responsible for gathering concrete data once a reasonably plausible case has been made for the necessity of that data to inform the discussion?

> Since communities will not be allowed to file blockers that do not "meet certain quality criteria"

The draft says "blockers aiming to change the course of a software project should meet certain quality criteria". Communities and whoever else can report blockers, and if those blockers miss something initially, they can be improved.

On whose shoulders the burden of collecting that data lies, it depends on the case. Sometimes that data will be easily available to everyone, sometimes it will be between hard and impossible for volunteers to dig it themselves, sometime that data will not exist yet.

When it is difficult to provide the data, development teams cannot reasonably demand to volunteers to provide it, neither can communities reasonably expect that development teams will have always the means to provide it.

I agree that development teams cannot reasonably demand data that the community cannot reasonably provide. I am concerned that the guidelines appear to lay all the burden on the community and none of the burden on the developers.

"The same quality criteria are expected from the developers or other contributors disagreeing with these blockers."

Thanks for clarifying that.

So from the wikilawyer's POV, then this would be fine (and the dev wins):

• User: I say this feature is used reasonably often and will be broken.
• Dev: Well, I say it tisn't and won't be.

and so is this (and the dev still wins):

• User: I say this feature is used reasonably often and will be broken.
• Dev: The logs say that only 1% of active editors used that feature this month.

but not this (user wins):

• User: This feature was used by 60% of admins this month, and it will be broken.
• Dev: Well, I still say that almost nobody uses it.

I don't see the use of language such as "wikilawyer" or "wins" as particularly helpful. The object of the guidelines is to layout expectations that will help developers and user work effectively together and discuss potential blockers in a useful way. Do you believe that the use of data in discussions over potential blockers is unhelpful? Would you like to propose a modification to the wording?

The sentence will be read by, and interpreted by, many people who are accustomed to the level of combativeness and wikilawyering that is prevalent in controversial areas at the English Wikipedia. Therefore, it's good to understand how that very large group will understand it.

I believe that data is a lovely thing. However, I don't believe that (volunteer or staff) devs should be required to provide data in response to any (volunteer[1]) editor who happens to make a statement that involves potentially quantifiable comments. I've seen discussions in which "all the time" turned out to mean "happens once or twice a week, but one of those times happened to me personally", or "editor makes a mistake in a judgment call twice a day" being called "a lot" without considering that the editor is dealing with 500 articles each day – and an error rate of just 0.4% is something that most of us still wish for.

[1] I'm ignoring the edge cases, such as the paid editor that opposes improvements to the spam blacklist.

I don't think that anyone is suggesting that devs should be required to produce data in response to every user who makes a potentially quantifiable comment, or that users should be required to produce data in response to every developer who makes a potentially quantifiable comment. So I'm not sure how that helps the discussion. I do suggest that when serious discussion turns on points that are important and capable of quantification, that we understand who is responsible for providing the data to support that discussion. I too have seen unsatisfactory arguments, and the object of this discussion is to manage down the rate at which they occur.

My first reply above was meant to answer your question: So far as I can tell, as currently written (but perhaps not exactly as intended), a dev only needs to provide data if the user provides data first (third pair of exchanges in the comment). If the user provide no data, then the dev can equally provide no data (first pair). That's what "same quality" means: if the user's quality is low, then the devs quality can be just as low, too.

Based upon past behavior, I expect that when WMF devs agreed that it was a serious discussion turning on points that are both important and reasonably simple to quantify, then they would voluntarily choose to provide data (second pair). (Volunteer devs would probably not, because their resources for collecting and interpreting data tend to be lower.) But as currently written, there is nothing that would require a dev to provide data unless the user does.

So from the wikilawyer's POV, then this would be fine

Since the goal is technical collaboration, it is fine what contributes to technical collaboration and it is not so fine what obstructs it and polarizes it. The Technical Collaboration Guideline is not a law, we are not aiming to make happy when writing it, and we should avoid falling in any temptations of . If the current writing can be improved in some way so the spirit of the recommendation is clearer and simpler to interpret, suggestions are welcome.

The guideline "Foundation Product teams should, as early as possible in the project timeline, share information about projects with the community" perpetuates the old one-way view of engagement with the Community. I suggest that this should read something like

• Formal project proposals made by Foundation Product teams should be accompanied by a description of the case for development. This should, and in the case of project that signficantly add to or change community workflows, must include a clear demonstration of community engagement and disussion of potential benefits and costs for the community.
• Project proposals must be ina friednly tone, use constructive arguments, data, actionable alternatives (one of which must always be do nothing') with a clear analysis.
• Demonstration of community engagement must include evidence of consensus when claiming to represent the view of a community or a large section thereof.
• Prior discussions and agreements within the community need to be taken into account. There must be good reasons to reopen a settled topic.

Of course some of these bullet points are reminisicent of the requirements for community blockers. And why would they not be?

Good points. Yes, development teams should share information when projects are still proposals open to discussion, and they should be subject to the high expectations about the quality of their communications.

I have edited the draft in order to reflect this idea better. To avoid duplicity, I have linked to other recommendations defining when to communicate new proposals and how. There might be a point in trying to make this more modular, setting common expectations for proposals and blockers. For now I have just aimed to link better the different recommendations.

I understand the reason for this point, and certainly do not advocate the opposite. But with the best will in the world constructive criticism is always hard to take. We do not want to get into a situation where valid and important points are discounted simply because they are perceived as unfriendly: the question is whether they are helpful. Mechamisms exist for dealing with behavioural issues already.

I think it doesn't harm to mention it.

MediaWiki.org posts and Phabricator tasks are editable. If the only problem in a blocker reported is the tone, the reporter and others can simply improve it. Dismiss a blocker only for its tone when it has substance would be wrong, but responding to unfriendly reports as if nothing had happened isn't right either.

Different communities might have different expectations for friendliness. It is not uncommon to see upset users landing for the first time in MediaWiki.org or Phabricator with a complaint, receiving quickly a remark about their tone regardless of how right their complaint might be. Adding the remark in the recommendation helps setting an expectation that goes in line with other efforts to improve friendliness and respect in Wikimedia technical spaces.