Talk:Wikimedia Engineering/Archive 1

The page could certainly use some design love. Feel free to edit mercilessly as long as the information hierarchy is preserved. guillom 09:49, 10 November 2011 (UTC)
 * I think it looks great! Thank you!    Thorncrag    19:34, 16 November 2011 (UTC)
 * Better late than never: The page now looks pretty enough :) guillom 15:18, 9 July 2014 (UTC)

"Or we can post on MediaWikiWiki, where non-techs are pretty routinely ignored"

 * Apart from generalizations and the implication of "we vs. them" in above quotation that I do not share: Personally I cannot judge how welcoming each forum or corresponding mailing list is, simply because I am not on every mailing list and cannot follow every wiki discussion/talk page, and I'm sorry to hear that other places that would be more appropriate to discuss high level issues don't feel useful. I can only repeat that Bugzilla is a bugtracker where specific issues or code enhancement requests are discussed. That's the scope of a bugtracker, and when maintainers decide that an issue will not get fixed, that's the maintainers' decision. Generalizing by using disagreement on a specific decision for questioning strategic priorities of a company or organization is simply out of scope for a bugtracker, as that's not a software bug or software enhancement request anymore. My guess would have been https://meta.wikimedia.org/w/index.php?title=Wikimedia_Forum here, and I hope that Risker will find a place where Risker's concerns receive appropriate attention. --AKlapper (WMF) (talk) 20:38, 7 July 2013 (UTC)

Identifying when it's too late
One reason it's hard to get user participation on MediaWiki software development is that this wiki's main namespace is full of many ideas thrown by paid developers, often uncategorised and/or lacking an infobox, whose stage of development is incomprehensible. Often an idea lingers for a while, or receives an inordinate amount of thinking/work by the proposer, and readers' interpretations will range from "it's a mere boutade" to "it's an irreversible decision enshrined in our fate". Commenting or working on embryonic ideas is laborious, so only people infatuated with the idea will comment.

Some ideas, however, have the invisible property of being really wanted by the powers that be: either intrinsically, or just for having received too high a personal investment to be abandoned. So at some random point in time they start being designed, and it's too late to comment on the basic idea; then at some other random point in time they start being implemented, and it's too late to comment on the design; then at some random point in time they start being put in use, and it's too late for about anything. Adding to confusion, those random points in time are not recognisable either, because what seems a finished product to some is a mere proof of concept for others. One thing is easy to see: the moment when something is thrown into your face (enabled for you on your wiki).

So, what can we do to make it clear in what stage an idea/proposal is and when it will be too late to do X?

How to tell someone "please, just trash this idea"? Or "thanks for the design proposal but it's not for us"? Or "thanks for the implementation but please stop"? Or (hopefully never) "ok I realise it's ready but we need to cut losses and give up with it"? --Nemo 12:42, 9 August 2014 (UTC)
 * Your post taught me the word boutade. I'm pretty excited about that. Thanks! --MZMcBride (talk) 00:32, 12 August 2014 (UTC)
 * I have certainly found that there's always one more page to post at. Perhaps it might help if there were members of staff whose job included gathering requirements from the contributors and other volunteers, and liaising between the community and the staff.  We could call them Community Liaison.  Unfortunately it has been explained to me  that this is simply not possible for WMF at the moment.  Deltahedron (talk) 18:46, 15 August 2014 (UTC)

Nemo, a useful question. (I'm sure you know this and it doesn't make things better, but people involved in planning and designing projects ask similar questions. And the related question of identifying when it's no longer time -- when an established Thing should be reëvaluated and possibly discontinued.)

I would find it helpful to have a standard infobox that's about 3x as detailed as the current ones, including a subset of:
 * Project parent / predecessor / successor / sibling
 * Inception date / lead maintainer / status
 * Link to bugzilla/phab search for all related items
 * Link to code and testing repos
 * Link to acceptance criteria, unit tests, data
 * Link to overview of feedback (for major releases)
 * Link to a timeline/roadmap
 * Cutoff dates for basic idea, design, alpha, early eval, beta, late eval, soft launch, full launch
 * Image of mascot wrestling with project-icon

A related infobox or navbox would be handy for an overview page for each cluster of related tools and ideas. They would be organized around a shared roadmap and goals, perhaps one or two teams, and would have some higher-level timelines: some projects depend on others.

Some entries could be color-coded based on status or the results of the evaluations, or whether the date indicated had been met or changed.

Which of the current project pages are the most informational / offer the best prototypes for this sort of structured data? Sj (talk) 01:04, 3 September 2014 (UTC)


 * The "standard, community-based process" is "whenever you have a great idea involving something technical, that you share the idea with the rest of your community at one of the Village Pumps (or some other centralized forum). If the rest of the community is interested, they'll point you to the right place (whether that's a bot request page, Bugzilla, or somewhere else)" .  Anyone who thinks this process (if indeed is is a prcess at all) could be improved might wish to join the brainstorm at Community_Engagement_(Product)/Process_ideas.  (For various reasons I will not be able to contribute there).  Deltahedron (talk) 18:23, 6 September 2014 (UTC)