[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