On Fri, Sep 23, 2016 at 5:19 PM, Greg Grossmeier <g...@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 > > to collaborate to improve the 'status' category of > > https://meta.wikimedia.org/wiki/2015_Community_Wishlist_Survey/Results. > 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 _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
