<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.
tl;dr: I'm trying to figure out why those concerns should demote it?
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?
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).
Greg