On Fri, Sep 23, 2016 at 5:19 PM, Greg Grossmeier <greg(a)wikimedia.org> wrote:
<quote name="C. Scott Ananian"
date="2016-09-23" time="16:10:37 -0400">
The suggestion has been raised (
https://www.mediawiki.org/wiki/Topic:Tbyqbjcuihhkhtk8) that one of the
Topics for the upcoming Developer Summit be the Community Wishlist.
It seems to me that the community wishlist is still not completely
embraced
by engineering/devs, perhaps partly because some
of the items are
impossible, or already on a roadmap, or others have priorities which are
out of sync with implementation difficulty. It is excellent work by the
Community Tech team that somehow still feels "not completely integrated".
I'm curious what "completely embraced by engineering" would be? Isn't
it
enough to have a full team structure with management (both engineering
and product) to be considered embraced? Do we need to do a group hug? ;)
Also, why does it need to be completely embraced by all devs? I know
many more fully staff projects that are even less embraced (by the
development community as a whole).
Also, what is "completely integrated" mean
in this context? I don't see
the tools that they are developing as being oddly non-integrated within
the workflows they are working with.
I'm just relaying a vague sense of reluctance, maybe a bit of NIH. I don't
see any wishlist items called out on
https://www.mediawiki.org/wiki/Wikimedia_Engineering/2015-16_Q1_Goals for
instance. I'm not sure they belong there! But (to answer your direct
question), it would certainly indicate that the wishlist has been
completely "integrated" and "embraced" by engineering if our
engineering-wide Q2 goals were in explicit alignment with wishlist items.
tl;dr: I'm trying to figure out why those concerns
should demote it?
I'm not trying to demote it; I'm arguing that we should be paying more
attention.
Perhaps one
way to structure a "wishlist" topic at the dev summit would
be
It
would be helpful to have an engineering
assessment for each wishlist item
detailing either:
(a) this is being actively worked on now by WMF staff
(b) this is on a roadmap for (roughly) XYZ date (with a link to the
roadmap),
(c) this depends on some other prior work (which is on a roadmap)
(d) this is technically sound but not a priority of the WMF (for
<reasons>, spelled out) so we are eager for community assistance
(e) there is serious disagreement about how to best accomplish this,
technically
(f) there is serious disagreement about how to best accomplish this,
non-technically (UX, social factors, mission creep, ongoing maintenance,
community A disagrees with community B, etc)
(g) this is, in the judgement of engineering, impossible or unwise.
It seems that this has been done for the top ten wishlist items, but we
could collaborate on filling out details on more of the items.
Would that need to be a DevSummit session? Or a pre-Summit call to
action/project?
I could support either. At the dev summit it might easier to corral the
disparate teams responsible. Doing this pre-summit is similar to
continuing the community tech team's current work on the survey -- which is
excellent, but what I'm trying to suggest are ways to make this a project
owned by all of us instead of just "a Community Tech thing".
A follow up
session could concentrate on items in categories (d) and (e),
attempting to resolve roadblocks. Category (f) would need
non-engineering
participation, perhaps at the next Wikimania.
This sounds like a reasonable use of time at the DevSummit. Most of
those 'non-technically' aspects are in-fact represented at the DevSummit
(UX, maintenance concerns, mission creep), and the others that aren't
decided represented there would, based on past experience, still benefit
from a conversation with the DevSummit group (social factors, community
disagreement).
Sure. We've had issues in the past with decision-making in the dev summit
when all the stakeholders weren't present, so I was just trying to narrow
our focus down to the subset of items where enough folks were present that
we could make meaningful decisions that stuck. Certainly informal
discussions about the other items would be helpful, and perhaps necessary
to set the stage for a future discussion. But I've heard from the summit
organizing team that they really want to have sessions which conclude with
actionable decisions. (cf "<qgil> In previous years a common frustration
has been the disconnect between Summit topics and what happened after in
our actual plans, work, allocation of resources, goals.... "
https://phabricator.wikimedia.org/E269 ).
--scott