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?
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.
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.