[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 schlessera):

 Replying to [comment:3 jdgrimes]:
 > Note that there is https://wordpress.org/ideas/, although I'm unsure
 whether any developers ever look at it (and it isn't particularly obvious
 to users either, I guess).

 Wow, I have never seen that one before. But yes, that's already pretty
 much one of the things I described above. So, now, imagine having this be
 available from within the dashboard for users, and using the collected
 data to make informed decisions about the roadmap for the next releases...

 Replying to [comment:4 helen]:
 > Based on this ticket and your linked post, it seems that your premise is
 that you're uncertain if WordPress is a democracy or a meritocracy, and
 that mentions of "the majority" imply some kind of democratic 1:1 voting
 system. Calling an open source project a meritocracy is loaded for good
 reason, but the reality remains that WordPress functions as a meritocracy.
 This is stated clearly in some places, including
 [https://wordpress.org/about/security/ the security whitepaper].

 I'm know it is run as a meritocracy, and I indeed fully support this. It
 is pretty much one of the foundational principles of the entire open
 source movement.

 I guess I have used terms that are too political to convey my message, and
 what's more, I'm myself not entirely whether what I propose would be a
 good or a bad idea.

 The point is, when large teams collaborate, there's two ways to
 productively conclude a discussion:

 1. Participants agree on a consensus.
 2. An authority takes a decision.

 The way I feel things are currently run, you either need to be able to
 achieve 1., or your discussions will turn in circles (or be post-poned
 from release to release), as no-one can or will impose 2.

 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.

 This is where the problem lies in my eyes. The needs and wants of the end-
 users are cited as facts and used as arguments, but most of the time, they
 are just opinions, as there's no means to verify them. And in the cases
 where such non-facts are used as arguments, no consensus is possible, so
 only a final authoritative decisions could properly conclude the
 discussion. And, as far as I can tell, this is not what happens in most of
 the cases.

 I know there's user tests being made for UX changes, for example, and
 there's server data being collected. 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? I don't suggest just using that data and blindly following it.
 But I think that, in this case, more data is better than less data...

 > "Design for the majority" is a philosophy and a goal, not some kind of
 literal process or a singularly decisive factor. I recognize that "the
 majority" constantly gets cited as an argument, but so do a lot of things
 - it does not inherently make that a good argument at all times. And don't
 forget, that same philosophies page that describes "design for the
 majority" contains a reminder about the vocal minority.

 Yes, I understand that this is not a literal process. But it is a
 philosophical goal that processes should be shaped by.

 > I don't want data collection efforts to center around what people want -
 certainly people's wants should be heard, but the data collected should be
 around what they do and how that informs things WordPress should do to
 better serve the needs that exposes. It seems that you agree with this at
 some level, and you know the vote you cite is not representative of "the
 people", so this ticket is extremely confusing to me.

 Yes, as I said, additional data should just inform the decisions, not bind
 them.

 > That particular poll also exposes a frequent problem with votes, in that
 nuance and reasoning is lost. Do people want Composer in core because they
 want to be able to use something that's in core, or do they want it
 because core can actually use it in an effective way? Is this more of a
 want than, say, a PHP 5.3 baseline, and could it be a million times better
 enabled if that were addressed first?

 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?

 > What's missing in your specific instance is not a voting mechanism, it's
 a trusted owner to guide the process of discovering needs and defining
 outcomes. What we do about usage data more broadly in WordPress is a
 valuable conversation to have and has been happening in fits and starts,
 but it's not something for a Trac ticket. My suggestion is to focus on
 getting the specific project that is #36335 productively moving before
 worrying about something like votes. It probably needs regular meetings,
 contribution direction on GitHub or wherever, focused writing prompts as a
 means to obtain some qualitative data (e.g. "what would having Composer in
 WordPress core do for you, and can you show a specific example"), and so
 on.

 Yes, I agree that a Trac ticket is not a good fit, but I thought it would
 be good enough to get the discussion started. If such a discussion is
 already happening, then I am sorry for duplicating efforts, as I am not
 aware of it, and would be happy if you can point me to the correct spot
 and close this ticket.

 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"... ;)

 > If you need help wrangling an owner or owners, then please ask for that
 help - software maintainers aren't just decision makers, they should also
 be facilitators.

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