[wp-trac] [WordPress Trac] #38064: Surveying system to gather user voices

[WordPress Trac]

#38064: Surveying system to gather user voices
-----------------------------+------------------------------
 Reporter:  schlessera       |       Owner:
     Type:  feature request  |      Status:  new
 Priority:  normal           |   Milestone:  Awaiting Review
Component:  General          |     Version:
 Severity:  normal           |  Resolution:
 Keywords:                   |     Focuses:
-----------------------------+------------------------------

Comment (by helen):

 Replying to [comment:5 schlessera]:
 > The point is, when large teams collaborate, there are two ways to
 productively conclude a discussion:
 >
 > 1. Participants agree on a consensus.
 > 2. An authority takes a decision.

 Two things: "consensus" means different things to people, and I think even
 with consensus, there is always a final decision-maker.

 > For 1., the discussion needs to follow clear argumentation, where all
 the arguments that are introduced by each of the sides can either be
 asserted or refuted. Only facts and hard data can be asserted or refuted,
 opinions can't. Arguments are asserted or refuted until only the valid
 ones are left, and these are then weighed against each other to determine
 whether it's an overall improvement or not.

 Not all things can result in "facts and hard data" - opinions are not
 inherently invalid and should not be outright disregarded. Facts and data
 still need interpretation, which is what I frequently see being written
 off as "opinion". Besides, why would anecdotal evidence not qualify as
 some sort of data? It may need to be weighted as less reliable, but it's
 still information you have at hand.

 I frequently find that circular arguments are happening not because of the
 actual information at hand, but rather the approach itself. Arguing
 against something is often far less productive than focusing on why
 something '''should''' be done.

 > But why not have a tool that allows us to query the users (that opted-
 in) directly? Why not let them tell you their biggest pain points? Why not
 let them help you define the priorities?

 As stated, I don't want to have people tell me their biggest pain points -
 I want them to show me what they do and then interpret the data collected.
 It's not about binding decisions, it's about the kind of data that is
 valuable to collect in the first place. Admin usage data collection is a
 blessed project - I've even outlined an MVP. What it needs is the same as
 what I've advised you to find - an active project owner.

 > Statistically speaking, that poll is complete nonsense, and not much
 more than a nice graphics, I'm fully aware of that. But against a "People
 don't want an autoloader" or similar argument, it's the best I could come
 up with. Should I have tried to run a normal survey with much more nuanced
 questions against the WP developer base as an unknown? How many responses
 do you think I would have gotten?

 1. "People don't want an autoloader" is so nonsensical as to be a non-
 argument IMO. I mean, really, "people want an autoloader" is just as true
 of a statement as "people don't want an autoloader" - it is not meaningful
 in any real way on its own. This isn't an argument around "wanting" an
 autoloader, it's about whether it makes sense for WordPress core to bundle
 and/or use one itself. What developers would gain from a bundled
 autoloader is important in assessing the value of the feature, but it's
 not about wanting the actual thing itself.
 2. Yes, I think more valuable data in this instance is qualitative data
 around the why and how of how developers currently and would like to
 leverage Composer and autoloading in general, and how the two things do or
 don't fit with WordPress core. This is why you need a project owner and
 process. You could collect responses in a GitHub issue, or distribute a
 survey via word of mouth, or whatever - people need reassurance that it is
 actually being actively collected and interpreted, and that's what an
 owner and process should help define. Responses will always be limited and
 biased in some manner, fretting about that will only guarantee that you
 never have anything to get a response to at all.

 I responded to your poll in the extreme small minority of "No, it's too
 early" because it was the closest response to "WordPress core doesn't seem
 to be structured in a way that actually makes sense with an autoloader and
 maybe a 5.3 baseline makes more sense first but I don't have any fixed
 opinion, so I guess this will let me see the results, in any case". That's
 another problem with those polls - there's no "other" and you can't view
 the results without choosing something, so who knows how many people just
 clicked one to get through (it'll bias toward the top option, which the
 audience itself is already biased toward). Why cite it at all?

 > Also, this was not merely pointing at that one ticket. I think that
 there's a more general sentiment of "not being heard" (by
 users/devs/specific communities/...) that would be alleviated by better
 "hearing tools"... ;)

 While I heartily agree that WordPress core does not adequately focus on
 feedback mechanisms, I would be very cautious about the difference between
 "I'm not being heard" and "I'm not getting my way". If there's a sentiment
 that "my desire for an autoloader hasn't been heard", I think that is
 pretty clearly not true - it's the outcome that isn't satisfactory. That's
 not any less legitimate, but it's a very different thing to focus on
 improving.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/38064#comment:7>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform