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

WordPress Trac noreply at wordpress.org
Fri Sep 16 19:23:51 UTC 2016


#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:7 helen]:
 > Two things: "consensus" means different things to people, and I think
 even with consensus, there is always a final decision-maker.

 Yes, agree.

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

 Yes, agree as well. When such an interpretation is written off as opinion,
 though, there's always rational arguments you can put forward to
 demonstrate the reasoning.

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

 I have come to the conclusion time and time again that arguing against
 something is much easier (and this is probably in part because of my
 previous government work). I think this is similar to how theories are
 proven or disproven in science. Depending on your theory, not even the
 biggest numbers of positive findings can prove a theory to be true in
 every case, but a single negative finding is enough to disprove it. But
 this is rather anecdotal here.

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

 I understand what you are saying. However, the users can only show you
 what they do based on what you previously built and allowed them to do. As
 a (silly) example, if your UI is just a big red button labeled "PUSH ME!",
 your tests will reveal something like: "84% of users push the 'PUSH ME'
 button. That button is hugely important and a full success.".

 Yes, this is a very simplified example, but I want to make a point.
 Watching users interact with your product is already very much biased in
 that they will only ever be able, for each of your functions, to either
 use it or not. How would such data be able to show you if something is
 completely amiss? Users have been trained and are forced to use what
 you've already decided to build for them before.

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

 Yes, totally agree. As I had already written in a response on that exact
 ticket, the end goal is not to have an autoloader be included, the end
 goal is to have a code base that is optimized to only load code when
 needed.

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

 You're absolutely right in that PHP 5.3 should be the absolute first step
 when talking about any modernization of the code base. On my personal list
 of crucial changes, this was number 1, with the autoloader only being
 number 3.

 However, after looking at a lot of discussions here, looking at the
 collected stats, and doing some research of my own, I've come to the
 conclusion PHP 5.2 compatibility will not be removed any time soon. The
 way I interpret the collected stats, the 5.2 sites do not contain many
 serious, active sites that are worth protecting, and their absolute number
 will not drop any further. The percentage was mostly decreasing because
 the overall number of installations was climbing, and this will soon hit a
 natural ceiling. So, my guess would be that we will not drop below an
 "acceptable" percentage threshold in the coming years, if the current
 criteria remains as is.

 That's the exact reason why I initially started commenting on the
 autoloader ticket. I wanted to prevent designing an autoloader API for WP
 & plugins/themes when we don't even have namespaces yet. So, I actually
 agree that it is too early for an autoloader to be included in form of an
 API. However, we can't start soon enough refactoring the code base, as
 that is needed, with an autoloader or not. The autoloader is a nice way of
 making moving files around less painful.

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

 Hehe, I guess my ticket does really come off as a "Bah, no one wants my
 autoloader"-whining, right?

 But, truth be told, the input I contributed to particular ticket has
 garnered more attention than I expected, and the fact that there was even
 a Composer autoloader committed within Core, even if only briefly, is a
 bigger achievement for me personally than I could have hoped for. At the
 very least, people are more aware of the issues at play than before.

 This ticket here however is not meant to have any impact on the autoloader
 one, which was merely the impulse that caused me to have a more
 "philosophical" moment.

 The reflection was more along the lines of: "Wow, half of the discussion
 in that ticket could probably have been avoided if we would have better
 tools to get representative data!".

 I just hate wasting time, and I not only optimize my code, but also my
 processes, and my life in general. The way that the discussions in some of
 the tickets evolve just doesn't feel right to me. I feel like dropped back
 into a three hour government meeting where everyone speaks, no-one
 listens,, and at the end there's neither agenda nor decisions.

 Maybe this is just me...

 Anyway, thanks already for taking the time to discuss this in a productive
 way and trying to read between the lines, I really appreciate it. If you
 estimate that this ticket itself is just another waste of time, and that
 there's already all the tools we need to make meaningful progress, then
 please just close this ticket. I probably don't know half of the sources
 of data that are available to the Core team, so this could well be just a
 meaningless rant on my part.

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


More information about the wp-trac mailing list