Hi everyone,
Abstract ----------- This mail doubles as an invitation to come to this week's ArchCom office hour (Phab:E285), and provides an attempt to provide answers to questions about the agenda of the Wikimedia Developer Summit (WikiDev17). I'm hoping we find a way to work with people who can't travel, and noting we're also working to make remote participation more rewarding. This emphasizes the importance of WikiDev17 being a better event for online attendance this year, and the primacy of online conversations in our community's decision making.
Table of contents for the rest: * ArchCom office hour E285 * Previous Dev Summits (2014-16) * The dangers of prior RFC requirement * Less spectators, more participants
ArchCom office hour ---------------------------- This week's ArchCom IRC office hour will be this coming Wednesday, https://phabricator.wikimedia.org/E285
Wednesday, 2016-09-28, 21:00 UTC (2pm PDT, 23:00 CEST) on #wikimedia-office
This is a continuation of the many conversations we've had on this mailing list (e,g, the "Wikimedia Developer Summit 2017: Registration Open" thread last week) and elsewhere about the summit.
Previous Dev Summits (2014-16) ---------------------------------------------- This is an admittedly biased version of history, based on my involvement in the program committee that is still forming. Quim is chairing the program committee, and I'm one of the members, but my understanding from Quim is that we're still waiting for some invitees to respond.
Previous years, we had a more explicit emphasis on "architecture" (e.g. even calling our 2014 event the "Architecture Summit"[1]). The ties between "architecture"<->MediaWiki<->wikitech-l are very strong. Additionally, the 2014 and 2016 events had very explicit instructions insisting on submission of MediaWiki RFCs[2].
The benefit of requiring submission of RFCs was that it caused many people to write down "this is what I want to talk about". There were many conversations leading up to last year's summit that might not have happened without such an explicit prompt. Many of the unconference sessions last year were discussions that were submitted as RFCs, but were turned down for plenary session time. Those unconference sessions benefited from the prep work.
The dangers of prior RFC requirement -------------------------------------------------------------- We don't intend to make the requirement so tough this year. A challenge we face is that many topics don't fit well into RFC form. "RFC" and "conversation" are not interchangeable terms. We hope that all RFCs are indeed conversations, but certainly not all conversations belong in RFCs. Last year, the RFC requirement also meant that all of the scheduled topics had Phab IDs associated with them. Is there some other short identifier we can use as a standard conversation identifier? Maybe Wikidata QIDs? ;-)
The hope is that WikiDev17 enriches conversations that are well underway *before* everyone shows up in San Francisco. Complicated conversations require a shared context, but humans have traditionally had a difficult time building shared context without physically putting everyone in the same room at the same time. Developers frequently want to cram "context building" into their discussion time, spending 70 minutes out of a 90 minute conversation time bringing attendees up-to-speed, so that we can have a "really good" 20 minute conversation.
A big fear: we fail to connect WMF staff developers with larger Wikimedia community developers. Meetings bust up unconference style into two camps: WMF staff led discussions where participation relies on having the kind of knowledge that one needs "insider" access to stay abreast of, and non-WMF staff led discussions where participants try to solve problems that WMF staff doesn't seem interested in solving.
A huge challenge: we can't *know* in September 2016 what conversations will be important in January 2017, but based on our experience with past Dev Summits, it's worth creating the opportunity for important conversations to happen. We have plenty of conversations that are still ongoing, and plenty of conversations many of you all likely know need to happen in January. Let's start the conversations we know about now, and *hope* that they're already done before the summit
Less spectators, more participants ---------------------------------------------- One thing we know from all of our experience: y'all don't want to make a point of coming to San Francisco to be talked at by someone. As in past years, we're working to bring up to 200 people together to have great conversations about the collective hopes of the Wikimedia development community. It's happening the same week as the Wikimedia Foundation All-Staff meeting, so the attendance will be heavily biased toward WMF staff, but we hope this isn't just us talking to ourselves. We're working hard to provide a framework for good conversations to happen; not for us to talk at you, or for you to talk at us, but for all of us to learn from each other. We're really happy with the satisfaction numbers from last year[3], and in particular, we hope that the 75 respondents (out of 84 responses) who agreed with "I would like to attend this event again next year" still believe that now.
Let's use the IRC meeting this week to prepare for the January event.
Rob
[1]: https://www.mediawiki.org/wiki/Architecture_Summit_2014 [2]: https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit_2016/Program [3]: https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit_2016/Lessons_Learn... (satisfaction numbers)
Thank you Rob! I am looking forward to Wednesday meeting.
On Tue, Sep 27, 2016 at 6:28 AM, Rob Lanphier robla@wikimedia.org wrote:
I'm hoping we find a way to work with people who can't travel, and noting we're also working to make remote participation more rewarding. This emphasizes the importance of WikiDev17 being a better event for online attendance this year, and the primacy of online conversations in our community's decision making.
Indeed. Anyone interested in improving remote participation in the Summit, please check https://phabricator.wikimedia.org/T146613
Quim is
chairing the program committee, and I'm one of the members, but my understanding from Quim is that we're still waiting for some invitees to respond.
Yes, I will send them a reminder. In any case, I think we have critical mass: https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit/About
all of the scheduled topics had Phab IDs associated with them.
I agree that RfCs are useful in some cases but not in all of them. However, I would still keep a single way to submit proposals as Phabricator tasks, in order to have one place with all the proposals. If the promoters of a specific proposal want to have the discussion elsewhere (in an RfC page, a plain wiki page...) then they can simply put a disclaimer in the task description and move the discussion there.
There are two possible novelties related to proposed and scheduled activities that we could try at the Summit:
* Phabricator form to submit Wikimedia developer Summit 2017 proposals (urgent because it blocks the opening of the call for participation) https://phabricator.wikimedia.org/T146377 * Consider using Phabricator Calendar events to schedule Wikimedia Developer Summit sessions (we have more time for this one) https://phabricator.wikimedia.org/T146749
Rob, Quim and Wikidatans,
Is there a current (curated) summary of all the good suggestions for WikiDev themes, and structuring of conference, in various email threads from the past week or two which you could possibly suggest looking at as key organizers of this? (I shared some Wikimedia language-ontology-translation related questions along with WUaS development questions, like in January 2016, I'd like to explore in the #wikimedia-office Office Hour this morning at 9am PST ).
Thank you.
Bests, Scott
On Tue, Sep 27, 2016 at 3:57 AM, Quim Gil qgil@wikimedia.org wrote:
Thank you Rob! I am looking forward to Wednesday meeting.
On Tue, Sep 27, 2016 at 6:28 AM, Rob Lanphier robla@wikimedia.org wrote:
I'm hoping we find a way to work with people who can't travel, and noting we're also working to make remote participation more rewarding. This emphasizes the importance of WikiDev17 being a better event for online attendance this year, and the primacy of online conversations in our community's decision making.
Indeed. Anyone interested in improving remote participation in the Summit, please check https://phabricator.wikimedia.org/T146613
Quim is
chairing the program committee, and I'm one of the members, but my understanding from Quim is that we're still waiting for some invitees to respond.
Yes, I will send them a reminder. In any case, I think we have critical mass: https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit/About
all of the scheduled topics had Phab IDs associated with them.
I agree that RfCs are useful in some cases but not in all of them. However, I would still keep a single way to submit proposals as Phabricator tasks, in order to have one place with all the proposals. If the promoters of a specific proposal want to have the discussion elsewhere (in an RfC page, a plain wiki page...) then they can simply put a disclaimer in the task description and move the discussion there.
There are two possible novelties related to proposed and scheduled activities that we could try at the Summit:
- Phabricator form to submit Wikimedia developer Summit 2017 proposals
(urgent because it blocks the opening of the call for participation) https://phabricator.wikimedia.org/T146377
- Consider using Phabricator Calendar events to schedule Wikimedia
Developer Summit sessions (we have more time for this one) https://phabricator.wikimedia.org/T146749
-- Quim Gil Engineering Community Manager @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Tue, 2016-09-27 at 14:23 -0700, Info WorldUniversity wrote:
Is there a current (curated) summary of all the good suggestions for WikiDev themes, and structuring of conference
If I get the question correctly that's likely https://www.mediawiki.org/wiki/Talk:Wikimedia_Developer_Summit For the structure, see last year's schedule on https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit_2016
Cheers, andre
Hi,
On 09/27/2016 03:57 AM, Quim Gil wrote:
- Phabricator form to submit Wikimedia developer Summit 2017 proposals
(urgent because it blocks the opening of the call for participation) https://phabricator.wikimedia.org/T146377
I have proposed the opposite on the ticket[1] - I believe we should be using mediawiki.org to organize the summit instead of Phabricator. I find it demoralizing that we cannot use our own online collaboration software to plan our own summit. We need more dogfooding[2], not less.
[1] https://phabricator.wikimedia.org/T146377#2670042 [2] https://en.wikipedia.org/wiki/Eating_your_own_dog_food
-- Legoktm
At the risk of threadjacking about dogfooding....
On Tue, Sep 27, 2016 at 2:45 PM, Legoktm legoktm.wikipedia@gmail.com wrote:
On 09/27/2016 03:57 AM, Quim Gil wrote:
- Phabricator form to submit Wikimedia developer Summit 2017 proposals
(urgent because it blocks the opening of the call for participation) https://phabricator.wikimedia.org/T146377
I have proposed the opposite on the ticket[1] - I believe we should be using mediawiki.org to organize the summit instead of Phabricator. I find it demoralizing that we cannot use our own online collaboration software to plan our own summit. We need more dogfooding[2], not less.
[1] https://phabricator.wikimedia.org/T146377#2670042 [2] https://en.wikipedia.org/wiki/Eating_your_own_dog_food
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....
The "Eating your own dog food" article talks a lot about Microsoft's use of the term, which makes sense because Microsoft was pretty proud of their dogfooding strategy. Dogfooding was the right strategy for Microsoft in the early 1990s, given what they were trying to accomplish, which world dominance of Microsoft operating systems. It worked well for them. 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.
The dogfooding article also points out many problems in the "Criticism" section, where it cites an IEEE magazine editorial on the subject. Here's a quote from the cited article[2]:
Also, dogfooding encourages the Not Invented Here syndrome. If the organization's philosophy is that employees must always use its own tools, scarce resources might get allocated to building tools that could easily be purchased from others, or worse yet, tools might get rejected simply because the company doesn't make them.
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.
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 2. Maintaining state metadata about tasks (e.g. bug reports, RFCs, etc)
...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? 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.
Rob
[1]: https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Guiding_Principles [2]: https://www.computer.org/csdl/mags/so/2006/03/s3005.html
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:
- 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?
- 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
Hi,
I am sorry but this discussion about this basic principle arrives too late. We have been using Phabricator to submit proposals in the past two years, and although the feedback about this was "polarizing", all in all it was considered positive with ideas for improvement [0] [1]. We could have discussed this topic some weeks ago but not now, in the week where we plan to open the call for participation (already delayed at least one week).
The promoters of a proposals still have all the freedom to decide where they prefer the discussion for that activity to happen, in the own task or elsewhere. I think we all agree that anything worth documented for the long term should be documented in MediaWiki.org, not in Phabricator tasks (or etherpads).
I will explain why I believe the current approach is good enough and even better than MediaWiki pages today:
On Wed, Sep 28, 2016 at 11:27 AM, Legoktm legoktm.wikipedia@gmail.com wrote:
- What things (mentioned above) do you (and others?) prefer about
Phabricator compared to MediaWiki?
Summit sessions are considered tasks themselves, not just a conversation happening in a room and eventually documented in a wiki page. Having a Phabricator task as common unit has these advantages:
* Assigned. It is clear to see whether a session is assigned to someone or not. That someone will have that task in their backlog, together with the rest of their Wikimedia work. They can set priority accordingly, just like the rest of work than needs to be done.
* Tags. Tasks can be associated to various related projects, and this generates notifications to people watching those projects, even if they have no clue that a Summit is going on. Teams running sprints can add their related Summit tasks to their sprints, assign points to them, whatever. Preparing a session is real work that takes real hours from other possible tasks.
* Blockers / Blocked by. Anyone interested in a session can define what needs to happen before it, what is depending on it, what actions come after it. This connects very well the Summit sessions with the work being done during the rest of the year.
* Board. Having an overview of all the Summit proposals presented and their status organized by columns is useful. Organizing a board moving tasks around is easy. Boards show open tasks by default and accept custom queries, which is useful for organizers and anyone willing to have a perspective of what is going on beyond their own session. For instance, do you want to check the sessions from the previous Summit that are still open, to see whether they could be pushed further in the next Summit? https://phabricator.wikimedia.org/project/view/1448/
- Should those features also be implemented or improved in MediaWiki?
It is easy to reply "yes, of course", but looking at the overall list of possible improvements of MediaWiki, I think the Wikimedia movement would prefer the investment of developer time in other areas. These cases are imho too niche from the perspective of writing free encyclopedias, dictionaries, media repositories, etc.
In any case, I wouldn't stop anyone willing to work on these features... but neither would I put the organization of the Summit at the expense of any of these features being implemented in MediaWiki. Wikimedia Phabricator is a Wikimedia tool that already provides those features, so...
- 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?
Although I have used MediaWiki as a mechanism to submit conference proposals (here and in my previous job), I don't think I know any MediaWiki user or any event organizer out of Wikimedia using MediaWiki to handle a call for participation. Wikimania and some WikiCons do, but I don't know the reasons why they do it, neither how happy are the organizers and the participants using those MediaWiki-based processes for an event.
My personal opinion is that we should know when to use MediaWiki and when not to use it, instead of using it always at all costs.
[0] https://www.mediawiki.org/wiki/MediaWiki_Developer_Summit_2015/Lessons_learn... [1] https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit_2016/Lessons_Learn...
It is easy to reply "yes, of course", but looking at the overall list of possible improvements of MediaWiki, I think the Wikimedia movement would prefer the investment of developer time in other areas. These cases are imho too niche from the perspective of writing free encyclopedias, dictionaries, media repositories, etc.
In any case, I wouldn't stop anyone willing to work on these features... but neither would I put the organization of the Summit at the expense of any of these features being implemented in MediaWiki. Wikimedia
Phabricator
is a Wikimedia tool that already provides those features, so...
To, me most of these strike me not so much as mediawiki lacking features as everyone already being on phabricator and wanting to integrate with those people. If you take out the integrate with existing phab content arguments, you are basically left with a bunch of features MediaWiki already has.
-- bawolff
I agree with bawolff, although I also see Quim's point about reopening this discussion at this particular point in time.
But I think it's an important conversation to have, even if it's not going to be directly relevant to this year's dev summit.
We used to have a project called "Flow", short for "Work Flow", which recognized that the WMF projects aren't *just* collaborative content creation, but also embody a lot of codified *process*. That seems to be exactly what Phab is providing for us.
Did we get scared off by our first attempt at solving the work flow problem? Or are we eventually going to try to tackle that? --scott
On Wed, Sep 28, 2016 at 11:22 AM, Brian Wolff bawolff@gmail.com wrote:
It is easy to reply "yes, of course", but looking at the overall list of possible improvements of MediaWiki, I think the Wikimedia movement would prefer the investment of developer time in other areas. These cases are imho too niche from the perspective of writing free encyclopedias, dictionaries, media repositories, etc.
In any case, I wouldn't stop anyone willing to work on these features... but neither would I put the organization of the Summit at the expense of any of these features being implemented in MediaWiki. Wikimedia
Phabricator
is a Wikimedia tool that already provides those features, so...
To, me most of these strike me not so much as mediawiki lacking features as everyone already being on phabricator and wanting to integrate with those people. If you take out the integrate with existing phab content arguments, you are basically left with a bunch of features MediaWiki already has.
-- bawolff _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Dnia 28.09.2016 Quim Gil qgil@wikimedia.org napisał/a:
Summit sessions are considered tasks themselves, not just a conversation happening in a room and eventually documented in a wiki page.
I think this kind of captures the opinions expressed here very well (if it could be one sentence).
a. Some folk prefer Phabricator because it provides workflow, tracking, boards, hierarchy (task->substask), explicit (scrollable) history, short URL's.
b. Others prefer MediaWiki because it is easier to cooperate in-place, visual editor, better search, good linking, readable titles and being loyal to our own tools.
I'd say (a) set of requirements is better for typical (classic) project management, for something bound in time and resources that needs to be managed swiftly.
Set (b) of requirements provides better community involvement, transparency and it is easier to maintain things that are perpetual work in progress (never need to be really "done").
(a) is better for "fast moving consumer goods" of sorts, (b) is better for long-term stuff.
But wiki is not a "final resting place" of a documentation polished elsewhere. Things should not become "eventually documented in a wiki page").
In my other note I wrote how CCC is using pentabarf submission and conference scheduling tool for (a) and MediaWiki for (b) probably for the same reasons we have here.
I think I kind of share both points of view: my event organiser's brain is with (a) but my volunteer heart is with (b).
One nice solution would be to teach Phabricator to treat links to wiki items as first-class objects that can be tagged, prioritized, deadlined, assigned, traced etc. I could imagine having MediaWiki pages as items on the project board and some correspondence between categories and phab tasks and boards. A casual look on the Phabricator does not reveal we have a Task for that (but it might be I could not find it) .
There is one more thing that may explain why we are having this discussion for now: Phabricator filled with content we have at the moment is very difficult to search. I literally have to remember titles of the tasks to try to somehow find them again. I have a feeling (that might be our fault and not software's) that it's filled with temporal junk which was there only for the purpose of some workflow/tracking sometime ago. I somehow feel our Phabricator instance is overloaded with those shooting starts (events, shortlived action items etc.).
This has started to annoy me some time ago (especially given my ad-hoc and seasonal interest in MediaWiki development) but it has never overflowed enough to say something about it, I just sighed and moved on.
I think many participants in this thread feel something similar and this thread just got hijacked to express something a bit broader than the original purpose of this discussion.
Saper
sent from a desktop device. please excuse my verbosity.
On 29 Sep 2016 10:10 pm, "Marcin Cieslak" saper@saper.info wrote:
Dnia 28.09.2016 Quim Gil qgil@wikimedia.org napisał/a:
Summit sessions are considered tasks themselves, not just a conversation happening in a room and eventually documented in a wiki page.
I think this kind of captures the opinions expressed here very well (if it could be one sentence).
a. Some folk prefer Phabricator because it provides workflow, tracking, boards, hierarchy (task->substask), explicit (scrollable) history, short URL's.
These are some things that Phabricator does very well, and it wouldn't make sense to reinvent the wheel to put them in MediaWiki - MediaWiki is a wiki after all, and not dedicated project management/bug tracker software.
b. Others prefer MediaWiki because it is easier to cooperate in-place, visual editor, better search, good linking, readable titles and being
loyal
to our own tools.
Phabricator's linking to tasks is good when you use the {resource} format. The MediaWiki visual editor is good, and it can be used on mobile, unlike Phabricator's preview mode when adding comments to tasks, which has never worked.
I'd say (a) set of requirements is better for typical (classic) project management, for something bound in time and resources that needs to be managed swiftly.
Set (b) of requirements provides better community involvement,
transparency
and it is easier to maintain things that are perpetual work in progress (never need to be really "done").
(a) is better for "fast moving consumer goods" of sorts, (b) is better for long-term stuff.
But wiki is not a "final resting place" of a documentation polished elsewhere. Things should not become "eventually documented in a wiki page").
Agree.
In my other note I wrote how CCC is using pentabarf submission and conference scheduling tool for (a) and MediaWiki for (b) probably for the same reasons we have here.
I think I kind of share both points of view: my event organiser's brain is with (a) but my volunteer heart is with (b).
One nice solution would be to teach Phabricator to treat links to wiki items as first-class objects that can be tagged, prioritized, deadlined, assigned, traced etc. I could imagine having MediaWiki pages as items on the project board and some correspondence between categories and phab tasks and boards. A casual look on the Phabricator does not reveal we have a Task for that (but it might be I could not find it) .
There is one more thing that may explain why we are having this discussion for now: Phabricator filled with content we have at the moment is very difficult to search. I literally have to remember titles of the tasks
Phabricator search is terrible. I have trouble every time I need to find something on Phabricator, to the point that it is easier to go and search through where I originally found out about the task, e.g. IRC logs.
to try to somehow find them again. I have a feeling (that might be our fault and not software's) that it's filled with temporal junk which was there only for the purpose of some workflow/tracking sometime ago. I somehow feel our Phabricator instance is overloaded with those shooting starts (events, shortlived action items etc.).
This has started to annoy me some time ago (especially given my ad-hoc and seasonal interest in MediaWiki development) but it has never overflowed enough to say something about it, I just sighed and moved on.
I think many participants in this thread feel something similar and this thread just got hijacked to express something a bit broader than the original purpose of this discussion.
Saper
sent from a desktop device. please excuse my verbosity.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
tom29739
(this was sent from my phone, so please excuse any grammatical/spelling errors)
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@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:
- 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.
- 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.
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 on behalf of Rob Lanphier wrote:
On Wed, Sep 28, 2016 at 2:27 AM, Legoktm legoktm.wikipedia@gmail.com wrote:
The edit history of that page is telling.
Be bold.
It may be a little naive to hope [dogfooding] 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.
What specifically are you arguing that MediaWiki was or was not designed to do? Please, go on.
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.
Another teaser here. What exactly is your vision for MediaWiki?
Are you really suggesting in your reply that supporting yet another markup language is more important and a higher priority than having usable categorization and tagging systems? I'm genuinely curious where you think time and effort is best spent.
MZMcBride
Hi!
In what way do you think that MediaWiki is not designed to promote and foster online collaboration?
Depends on purpose of collaboration. For some things - like project maintenance, planning, tracking, etc. - it's far from the best. Deep discussion is also not without friction (phab is not ideal in that regard either btw) - keeping track of several discussions becomes very hard, especially if a number of people participates. Flow may make matters better but it's not enabled everywhere, and not on mediawiki.org.
That said, for collaborative document editing MediaWiki is not bad - but definitely can use some improvement. Things that specifically come to mind are:
1. Ability to comment directly on parts of text. Right now to discuss the paragraph you need to go to talk, and then each time go back and forth to keep in mind what we're talking about. High friction.
2. Ability to submit/approve changes. I know "be bold" works well in some cases, but in others I wouldn't presume to edit somebody's text without their approval. However, if I could submit an edit for their consideration, which they might approve - that might work better.
3. Better diff notifications (you mentioned it).
The delta for MediaWiki to become good task/project management is very big IMHO, so I'm not sure it makes sense to go there instead of using existing solutions.
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:
- Doling out short unique identifiers of tasks, events, etc
Every page in MediaWiki is assigned a unique page_id. You can visit an
It does. I'm not sure the UI allows you to discover this fact though. OTOH, I agree that textual IDs are better for many things when we're talking about unique documents (a-la RFCs). For stuff like bugs or fine-grained tasks, IDs usually work better though.
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.
I agree here. For collaborative document editing Phabricator is not the best solution, and IMHO not better than MediaWiki.
This of course is general things, not specific to decision to use Phab for specific task of CfP, which Quim seems to have decided already.
wikitech-l@lists.wikimedia.org