Re: [Wikitech-l] Wikimedia Developer Summit 2017 discussion

[tom29739]

On 29 Sep 2016 10:10 pm, "Marcin Cieslak"  wrote:
>
> Dnia 28.09.2016 Quim Gil  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)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Wikimedia Developer Summit 2017 discussion

[Marcin Cieslak]

Dnia 28.09.2016 Quim Gil  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.


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Wikimedia Developer Summit 2017 discussion

[Marcin Cieslak]

Dnia 28.09.2016 Yaron Koren  napisał/a:
> Hi Quim,
>
> Most relevantly, the Chaos Communications Congress wiki uses the Semantic
> Forms [1] extension to handle submissions - speakers use a form to enter
> their talk proposals. I don't know how exactly talks are approved, or
> whether the form is used for approving/rejecting talks too - or, for that
> matter, whether they have any sort of real screening process. But the basic
> mechanics are that forms are used for entering all the relevant information
> about each talk, including tags (among many other fields).

Yaron, this is interesting: 

I know that CCC is using MediaWiki extensively to show the programme and enable
cooperation between participants (incl. sharing a ride or dating),
but when I has a privilege to speak at the Congress in 2014 they used
a homegrown tool called pentabarf to collect and evaluate submissions.

By the way I am amazed how well their MediaWiki usually performs under
a very heavy load during the event.  

Saper


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Wikimedia Developer Summit 2017 discussion

[C. Scott Ananian]

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



-- 
(http://cscott.net)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Wikimedia Developer Summit 2017 discussion

[Andre Klapper]

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
-- 
Andre Klapper | Wikimedia Bugwrangler
http://blogs.gnome.org/aklapper/

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Wikimedia Developer Summit 2017 discussion

[Stas Malyshev]

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:
>> 1.  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.
-- 
Stas Malyshev
smalys...@wikimedia.org

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Wikimedia Developer Summit 2017 discussion

[MZMcBride]

Wikitech-l on behalf of Rob Lanphier wrote:
>On Wed, Sep 28, 2016 at 2:27 AM, Legoktm 
>wrote:
>> [1] https://www.mediawiki.org/wiki/Principles
>
>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



___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Wikimedia Developer Summit 2017 discussion

[Rob Lanphier]

Hi Legoktm,

Quim explained why this discussion is probably a moot point (for this
year's summit) at .  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  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 = 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
>  is way more
> useful and readable than .
> 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 | {T21}  |  {T22}  | {T23} |
| 2pm | {T24} | {T25}| {T26} |

| Tuesday | Room 1 | Room 2 | Room 3 |
| 10am | {T27}  |  {T28}  | {T29} |
| 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

A, 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

Re: [Wikitech-l] Wikimedia Developer Summit 2017 discussion

[Brian Wolff]

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

Re: [Wikitech-l] Wikimedia Developer Summit 2017 discussion

[Yaron Koren]

Hi Quim,

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.


There's SMWCon (the Semantic MediaWiki Conference), although you could say
that this too is an example of "dogfooding". But the annual Chaos
Communications Congress [0] also uses MediaWiki for its talk submissions,
and that's a real conference, which had over 13,000 attendees last year.

Most relevantly, the Chaos Communications Congress wiki uses the Semantic
Forms [1] extension to handle submissions - speakers use a form to enter
their talk proposals. I don't know how exactly talks are approved, or
whether the form is used for approving/rejecting talks too - or, for that
matter, whether they have any sort of real screening process. But the basic
mechanics are that forms are used for entering all the relevant information
about each talk, including tags (among many other fields).

Here's an example of one such page for a session:

https://events.ccc.de/congress/2015/wiki/Session:A_New_Business_Model_for_the_Internet

...and here's the form used to create/edit it:

https://events.ccc.de/congress/2015/wiki/index.php?title=Session:A_New_Business_Model_for_the_Internet=formedit

Why have Wikimedia events never used MediaWiki + Semantic Forms to manage
their talk proposals? I don't know - it might be a case of "not invented
here" syndrome, ironically, since Semantic Forms is a non-Wikimedia
extension. But it's certainly an option.

[0] https://en.wikipedia.org/wiki/Chaos_Communication_Congress
[1] https://www.mediawiki.org/wiki/Extension:Semantic_Forms

-Yaron

-- 
WikiWorks · MediaWiki Consulting · http://wikiworks.com
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Wikimedia Developer Summit 2017 discussion

[Quim Gil]

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 
wrote:

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



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


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

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_learned#Phabricator
[1]
https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit_2016/Lessons_Learned#Use_of_the_combination_of_etherpads.2C_Phabricator_and_wikis_to_coordinate_the_sessions

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

Re: [Wikitech-l] Wikimedia Developer Summit 2017 discussion

[Legoktm]

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
> 
> 
> 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 = parameter to index.php. But, I
don't see how this is relevant to summit proposals. I think a URL like
 is way more
useful and readable than .
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 

Re: [Wikitech-l] Wikimedia Developer Summit 2017 discussion

[Rob Lanphier]

At the risk of threadjacking about dogfooding

On Tue, Sep 27, 2016 at 2:45 PM, Legoktm  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

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Wikimedia Developer Summit 2017 discussion

[Legoktm]

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

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Wikimedia Developer Summit 2017 discussion

[Info WorldUniversity]

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  wrote:

> Thank you Rob! I am looking forward to Wednesday meeting.
>
> On Tue, Sep 27, 2016 at 6:28 AM, Rob Lanphier  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
>



-- 

- Scott MacLeod - Founder & President

- http://worlduniversityandschool.org

- 415 480 4577

- PO Box 442, (86 Ridgecrest Road), Canyon, CA 94516

- World University and School - like Wikipedia with best STEM-centric
OpenCourseWare - incorporated as a nonprofit university and school in
California, and is a U.S. 501 (c) (3) tax-exempt educational organization.


World University and School is sending you this because of your interest in
free, online, higher education. If you don't want to receive these, please
reply with 'unsubscribe' in the body of the email, leaving the subject line
intact. Thank you.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Wikimedia Developer Summit 2017 discussion

[Quim Gil]

Thank you Rob! I am looking forward to Wednesday meeting.

On Tue, Sep 27, 2016 at 6:28 AM, Rob Lanphier  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

[Wikitech-l] Wikimedia Developer Summit 2017 discussion

[Rob Lanphier]

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,


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