https://bugzilla.wikimedia.org/show_bug.cgi?id=64921
--- Comment #28 from Quim Gil <[email protected]> --- This discussion beyond the topic of the bug report should be moved somewhere else, or we will repeat it again in another bug report. (In reply to MZMcBride from comment #27) > I'm not questioning responsibility as much as I'm saying that what you're > describing isn't how Wikimedia or MediaWiki development operate. The Wikimedia movement has different ways of operating, sometimes they differ and contradict each other, and still they are all Wikimedia ways. MobileFrontend is maintained by the WMF Mobile team according to https://www.mediawiki.org/wiki/Developers/Maintainers . This team has a documented process to release new features through a beta mode that, according to Jon Robson in https://en.wikipedia.org/wiki/Wikipedia:Requests_for_comment/Mobile_site_strapline , has shipped this feature since April 2013. This team also works in coordination with the WMF Product Management and Design teams (and QA, etc). Maryana is the product manager appointed currently for MobileFrontend, and her role is to coordinate the priorities of this product, among other things. The WMF is part of the Wikimedia movement, and therefore all of the above is part of how Wikimedia or MediaWiki development operate. MZMcBride or any other community member has the right to object to any development plan or implementation, providing constructive argumentation and eventually requesting comments from any of the many communities operating within the Wikimedia movement. Appealing to previous community discussions on signatures, pointing to inconsistencies between desktop and mobile, starting an RfC at https://en.wikipedia.org/wiki/Wikipedia:Requests_for_comment/Mobile_site_strapline ... are also part of how Wikimedia or MediaWiki development operate. The problems come when WMF teams and Wikimedia volunteers share all of the above together with aggressive language and aggressive use of Bugzilla status fields, one step inviting to the other in a counterproductive escalation. The structure of this report shows a pattern that will cause conflict frequently, here and in most free software projects: 00:00 Volunteer files a bug 00:10 Employee replies in disagreement - comment #2 00:26 A constructive discussion continues, a second employee joins. 01:04 A third employee joins, resolving that this report is a WONTFIX. 01:56 The volunteer reopens and continues with the discussion. At this point we have several people upset, and a growing potential to upset more the new volunteers and employees that learn about this discussion. This is no justification for anybody to question the role of anybody or to be dismissive. However, it is useful to note that leaving the bug open while the discussion is open makes everything easier, especially for product owners and lead developers. Reporters on the other hand will need to bring better arguments and find wider community feedback, either gaining support for their cause or putting themselves in evidence. In the meantime, the team members can join the community discussion as they see fit, mark this report low priority, and continue with their work and their plans until the situation is clear. Waiting can be never bad for the developer team: the feature is deployed and any feedback can be useful to improve the current situation. -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
