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...