<quote name="C. Scott Ananian" date="2016-09-23"
time="17:47:52 -0400">
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.
Wrong year :)
https://www.mediawiki.org/wiki/Wikimedia_Engineering/2016-17_Q1_Goals#Commu…
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.
https://www.mediawiki.org/wiki/Wikimedia_Engineering/2016-17_Q2_Goals#Commu…
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.
Right right. Gotcha.
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.
I guess I just don't see the need for it to be filled out by "the teams
responsible". The community wishilist was a community filled in list,
after all.
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".
Gotcha more now! That's a bigger meta question at that point, I guess :)
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 ).
Yeah, that'd be the downside of trying to talk about those parts of the
list. And yes we (I'm on the planning committee now) do want more
actionable next steps from these discussions this year (or at least,
better commitment to actually do the actions!).
tl;dr: I see your points better now, thanks! I'm still pro getting much
of the wishlist items 11 and up to be filled in pre-summit, but I see
your point about it might be a better topic for Wikimania than the
DevSummit to go through many of them.
Greg
--
| Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E |
| Release Team Manager A18D 1138 8E47 FAC8 1C7D |