According to the model that you were using, whether an issue actually blocks deployment is ultimately determined by the dev team
If you'd like to discuss the theory involved in that model, and what would happen after the dev team did that, I suggest we move that dark topic to a discussion non-specific to the NewEditor. I'd like to take a shot at aiming this discussion towards collaborative progress on this particular case.
On the "simulated previews" task, you were asked to clarify the nature of your request.
Please note that I terminated "my request" five months ago. That was the day I opened the RFC. At that point I considered my requests null and void. The community would either reject them, or modify them, or assert them itself.
The Community now owns the two Phab tasks. When the RFC closed I updated each task description with the verbatim RFC problem statement, the verbatim RFC proposals, and the close rendering each proposal as the voice of the community. The proposal-text states the nature of the task.
I am here as a random individual inquiring how the WMF intends to respond to the Community.
As a closely involved random community member, I am happy to offer any insight or advice or assistance in interpreting the community consensus, for successfully resolving the Phab tasks, or for assisting any potential ConsensusCanChange discussions between the WMF and Community.
I'll try to clear up some misunderstanding. You asked if this is improvements that will be valuable for years to come, or temporary changes that have some practical value today but will have to be reverted later. This is a permanent improvement.
You said: The question is essentially binary, so you need to choose one of the two options. The task is option 3 or option 4. If I may, I'll phrase your 'binary' options like this:
- Keep fake previews and play whack-a-mole fixing only some rendering errors.
- Keep fake previews and play whack-a-mole fixing only some rendering errors. By the way we'll be doing double-work whacking some moles twice, adding then removing some bits of code from the fake preview.
1&2 are fundamentally the same option. Your second option just shines an extra spotlight on why fake preview is a design error. If you're adding and removing preview code, the design is wrong. Preview-specific code should be relatively small and almost maintenance-free.
- Previews must use the article-view rendering engine. The preview button in the current wikitext editor tells the server 'show me this article'. It simply reuses the article rendering engine to show an actual preview of the article. The NewEditor preview button tells the server "show me what it would look like in VE". That's stupid. The task is for the NewEditor to do what the current editor does, ask for actual article renders. Quoting the RFC, This fixes the assorted rendering errors all at once, and it ensures that previews remain synchronized with article views when any changes are made to the software. Preview errors won't exist, work to update or fix previews won't exist, and any code changes to article views automatically apply to previews for free.
- We could happily retain our current wikitext editor. Note: Qgil offered this as an example of an appropriate actionable blocker when he was explaining the TCG. His exact phrase was Thank you, we are happy with the current status.
- Implicit: If the WMF feels that important evidence or arguments were not considered in forming the consensus, they could be raised in a new ConsensusCanChange discussion. That can alter or void the task.
I don't think that there is anything more to be said about the load times right now.
You missed the question I asked. I didn't ask about progress. I asked whether the WMF anticipates the task can and will be successfully resolved. If the issue was examined and the answer is 'yes', it would be helpful to post that answer. If the answer is "we have no idea" and the WMF is blindly driving the train forwards, that's a problem.
Do devs have a credible expectation that load times can be improved to be comparable to our current wikitext editor? Or is there just a vague hope that load times can be improved by useless few percent?
For the project overall, the options are:
- We happily keep the current editor.
- The NewEditor will successfully resolve both issues, with genuine previews and load times reasonably comparable to the current editor.
- Opening WMF-Community discussions to cooperatively form a plan.
- Boldly deploy against consensus and see how it goes. I suggest any dark details go in a separate discussion about non-collaborative cases in general.
I am hoping for any of 1,2,3.