Hi Legoktm, Quim explained why this discussion is probably a moot point (for this year's summit) at <https://phabricator.wikimedia.org/T146377>. He's the chair of Program committee, and he's calling the shots on our tooling choice. He's said "it is too late to start a discussion about Phabricator vs MediaWiki to handle the call for participation. "
That said, I'll provide a more detailed reply, because someone is wrong on the Internet! ;-) More inline.... On Wed, Sep 28, 2016 at 2:27 AM, Legoktm <legoktm.wikipe...@gmail.com> wrote: > 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? That is a loaded question. I believe that Phab is better than MediaWiki at: 1. Doling out short unique identifiers of tasks, events, etc 2. Maintaining state metadata about tasks (e.g. bug reports, RFCs, etc) >> 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. That is technically correct, which, as we know, is the best kind of correct! ;-) > 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? Readable: yes. Useful: depends on what your use is: * Readability: yes * Using as a canonical identifier: no * Verbally giving someone the exact, unambiguous identifier for a proposal: no * Expanding a short ID into a long topic name: no The thing that I found *really* useful last year was being able to really quickly make a schedule. I could drop text like this in a comment: | Monday | Room 1 | Room 2 | Room 3 | | 10am | {T200001} | {T200002} | {T200003} | | 2pm | {T200004} | {T200005}| {T200006} | | Tuesday | Room 1 | Room 2 | Room 3 | | 10am | {T200007} | {T200008} | {T200009} | | 2pm | {T200010} | {T200011} | {T200012} | ...and have it render as two 4x3 tables, with all of the task numbers in curly brackets replaced with the full title of the task. I could cut and paste the comment text around, and drop it into plain text emails (like this one) and have people get the basic semantics of what I was referring to. >> 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. That seems like a lot of work where the time and effort is better spent elsewhere. >> 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 Ahhhh, now we're getting to the real issue. I agree, I find this frustrating too. Much of the scramble getting things together for WikiDev16 (and my increased involvement in ArchCom facilitation) really piqued my interest in markup conversion. I would love for us to have better interoperability with Phabricator. However: 1. Phabricator isn't likely to switch to [Wikitext][1] 2. We're not likely to switch to [Remarkup][2] [1]: https://www.mediawiki.org/wiki/Wikitext [2]: https://secure.phabricator.com/T2849 Hence, why I attempted to prod Phab upstream to either play to win or just implement Markdown. That's also why I submitted my Markdown RFC (T137946) and why I'm interested in working with the Parsing team on the Wikitext spec (T142803). The poor interoperability between Phabricator and MediaWiki is both an enormous pain the butt, and symptomatic of a much larger problem: nobody cares about interoperating with us. BTW, do you really believe that Phab not supporting "convenient templates like {[wg}} or {{ll}}" is a problem with Phabricator? > 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 hope upstream improves Phab's search capabilities, but I think that's orthogonal to this discussion. > 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? > [...] > [1] https://www.mediawiki.org/wiki/Principles The edit history of that page is telling. > 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. > [If investing in Phabricator] comes at the cost of improving > MediaWiki and by extension, the Wikimedia movement, then I think we > should be extremely cautious. > > [2] https://phabricator.wikimedia.org/T6323 I don't think that forcing Quim and the WikiDev17 Program Committee to use MediaWiki instead of Phabricator will further delay the implementation of T6323. Do you? Rob _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
