https://bugzilla.wikimedia.org/show_bug.cgi?id=69445
--- Comment #32 from Quim Gil <q...@wikimedia.org> --- I think the effort of bringing all developers under the same roof is worth, and mediawiki.org is the right roof. But going back to the definition of the sane code-review process, some ideas came up from a casual email chat. Summary in sequential order: Erik proposed to investigate the idea of Phabricator with a web based interface for editing files, as a possibility to bring easy-as-in-editing-text development closer to proper code review and continuous integration with automated QA. We checked upstream, but generally speaking they are not enthusiastic with the idea. See their reasoning at https://secure.phabricator.com/T6008#7 For different reasons, Legoktm proposed to go back to the idea of a MediaWiki-based code review. Let me paste: "(...) we could just put a revision id in the gadget definition: "scripts": {"foo.js": 123, "bar.js": 456}, "styles": {"baz.css": 789}, Or something like that. So anyone can edit (maybe still restricted by a userright or maybe not) the JS/CSS pages, but their changes don't actually take effect until the gadget definition is updated by someone with those rights (+2). This allows us to take advantage of wiki process like be bold, revert, discuss, but still impose a review requirement by someone with "+2" rights. In some ways it's like SVN." As Legoktm explain, there is a precedent of this type of process in the workflow for approving EventLogging schemas, where many can edit the schemas but only a few can point to a new version (the +2 equivalent). https://www.mediawiki.org/wiki/Extension:EventLogging/Guide#Peer_review -- 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 Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
