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.wikipedia(a)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