<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 <[email protected]> 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#Community_Tech > 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#Community_Tech > > 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 > > > 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. 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 | _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
