Hi, On 09/27/2016 09:55 PM, Rob Lanphier wrote: > It's really unfortunate that you consider use of Phabricator to be > demoralizing, though. I don't want to push something that seems > demoralizing to a great contributor like yourself. More on this in a > bit.... > > It may be a little naive to hope it will > somehow make our software better at doing the thing it was designed to > do when we try to force it to do something it wasn't designed to do.
In what way do you think that MediaWiki is not designed to promote and foster online collaboration? > The dogfooding article also points out many problems in the > "Criticism" section > <snip> > > Sometimes, a non-Wikimedia system may be the best food ... er, tool > for the job. We shouldn't compromise on WMF's guiding principles[1] > (which we hope are a reflection of movement principles), but we > shouldn't insist on using our own systems when a system developed > and/or maintained by someone else would be the best tool for the job. > Let's shoot for better interoperability with the rest of the free > software world, rather than mindless world dominance of > Wikimedia-controlled software. Sure, I agree with that, and my blanket statement about dogfooding being a good thing was too broad. > So, that's my rebuttal to the suggestion that we need "more > dogfooding" I think we do need to get better at using our software. > Certainly, MediaWiki is hard to beat at collaborating on prose, > providing great attribution functionality about article changes. I've > frequently called for ArchCom-RFC authors to move the bulk of the > prose of their RFCs onto mediawiki.org. However, Phabricator is > really good tool for a couple of things: > 1. Doling out short unique identifiers of tasks, events, etc Every page in MediaWiki is assigned a unique page_id. You can visit an article by it's page id with the &curid= parameter to index.php. But, I don't see how this is relevant to summit proposals. I think a URL like <https://www.mediawiki.org/wiki/WMDS17/Shadow_namespaces> is way more useful and readable than <https://phabricator.wikimedia.org/T115762>. Wouldn't you agree? > 2. Maintaining state metadata about tasks (e.g. bug reports, RFCs, etc) Agreed. That said, MediaWiki categories can be pretty powerful, and then you can combine them with templates or things like DPL. We already have such a system set up for RfCs on mediawiki.org, I think making a similar template and set of categories for summit proposals would be easy. > ...plus many other things we use Phabricator for. > So, what about our use of Phab for this makes you glum? Is there a > way we can convince you that it's not so bad? For the purposes of drafting a document, asking other people to review and contribute to it, and then discussing it, Phabricator seems like a bad fit. Instead of being able to use an awesome VisualEditor, I'm forced to use remarkup. Instead of being able to use convenient templates like {[wg}} or {{ll}}, I'm forced to use clunky external links. Instead of automatically getting a CodeEditor when writing up some mock PHP/JS, I have to open a plain text editor on my laptop for proper tabs and brace completion and copy/paste it back in my browser. And if you want to try searching anything in Phab...good luck. Nik, Chad, and the Discovery team have done and are continuing some great work on improving MediaWiki's search, while Phab doesn't support basic features like stemming. I'm generally a fan of Phabricator as a bug tracker - not as a collaborative document editing platform. So what demoralizes me, is that I and my peers have invested a significant amount of time, effort, etc. to help build up MediaWiki as a collaborative editing platform, yet, we don't use it. MediaWiki is the platform for the Wikimedia movement[1]. Why are developers special here? Now, I'm sure that there are nice features of Phabricator that people prefer. For example, I really like getting diffs in email notifications. But...that's been a MediaWiki feature request[2] since 2005! I suspect that there are other features people like about Phab where MW does a poor job. So, let's turn your question around. 1. What things (mentioned above) do you (and others?) prefer about Phabricator compared to MediaWiki? 2. Should those features also be implemented or improved in MediaWiki? 3. Is the lack (or degraded quality) of the feature in MediaWiki a blocker to prevent you from doing whatever you wish to do (in a timely, stress-free manner, etc.)? If so, do you think that other MediaWiki users or Wikimedians are running into the same issue as you? > I'm open to being > convinced that we should stop using Phab for as much as we are, but > right now, it makes me happy that we have a tool that is rapidly > improving without Wikimedia Foundation needing to invest very much > money in it. It makes me especially happy that Phab is free software, > and that the time and money we invest in it is making the universe of > free software better. The Wikimedia Foundation has invested a significant amount of money in Phabricator, via resourcing, staffing, training users, etc. I too am glad when we are able to contribute to the growth of another free software project, however, if that comes at the cost of improving MediaWiki and by extension, the Wikimedia movement, then I think we should be extremely cautious. [1] https://www.mediawiki.org/wiki/Principles [2] https://phabricator.wikimedia.org/T6323 -- Legoktm _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
