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.
Topic on Talk:Technical Collaboration Guidance/Community decisions
> 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.