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

[Wikitech-l] WikiDev'17 main topics and their owners (next steps)

[Quim Gil]

(Posted at https://www.mediawiki.org/wiki/Topic:Tcg07knzz72wixak and pasted
here for convenience)

The Wikimedia Developer Summit 2017 aims to focus the call for
participation around these main topics:

* A plan for the Community Wishlist 2016 top results
* Handling wiki content beyond plaintext
* A unified vision for editorial collaboration
* Building a sustainable user experience together
* Useful, consistent, and well documented APIs
* How to manage our technical debt
* How to grow our technical community

You can find more information about these topics and how we selected them at
https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit and
https://www.mediawiki.org/wiki/Topic:Tb6bztglijowk8x3

The next steps are:

* Each main topic needs at least one owner, who will assure that the topic
is well promoted in the right places, the right activities are proposed,
and the right people participate in them with common goals. These owners
will join the Program committee
https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit/About

* Each main topic needs good quality and quantity of proposals submitted,
so a good selection can be made for the pre-scheduled Summit program.

* Each main topic needs its own wiki page for information, coordination,
discussion, and documentation.

If by the end of October a main topic is still missing an owner, a critical
mass of proposals and/or a decent wiki page, then the chances are that such
main topic will be dissolved. If that happens, the activities proposed can
be still pushed by their promoters in the context of the Unconference. Just
like the rest of proposals not fitting under the main topics.

-- 
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] The Revision Scoring weekly update

[Aaron Halfaker]

Hey,

This is the 23rd weekly update from revision scoring team that we have sent
to this mailing list.

New development

   - We implemented and demonstrated a linguistic/stylometric processing
   strategy that should give us more signal for finding vandalism and
   spam[1].  See the discussion on the AI list[2].


   - As part of our support for the Collaboration Team, we've been
   producing tables of model statistics that correspond to set of
   thresholds[3].  This helps their designers work on strategies for reporting
   prediction confidence in an intuitive way.


Maintenance and robustness

   - We had a major downtime event that was caused by our logs being too
   verbose.  We've recovered and turned down the log level[4].


   - We made sure that halfak got pings when ores.wikimedia.org goes down[5]


Datasets

   - We created a database on Wikimedia Labs that provides access to a
   dataset containing a complete set of article quality predictions for
   English Wikipedia[6].  See our announcements[7,8,9].


1. https://phabricator.wikimedia.org/T146335 -- Implement a basic scoring
strategy for PCFGs
2. https://lists.wikimedia.org/pipermail/ai/2016-September/98.html
3. https://phabricator.wikimedia.org/T146280 -- Produce tables of stats for
damaging and goodfaith models
4. https://phabricator.wikimedia.org/T146581 -- celery log level is INFO
causing disruption on ORES service
5. https://phabricator.wikimedia.org/T146720 -- Ensure that halfak gets
emails when ores.wikimedia.org goes down
6. https://phabricator.wikimedia.org/T106278 -- Setup a db on labsdb for
article quality that is publicly accessible
7. https://phabricator.wikimedia.org/T146156 -- Announce article quality
database in labsdb
8. https://lists.wikimedia.org/pipermail/ai/2016-September/91.html
9.
https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)/Archive_149#ORES_article_quality_data_as_a_database_table

Sincerely,
Aaron from the Revision Scoring team
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] 2016-09-28 Scrum of Scrums meeting notes

[Grace Gellerman]

https://www.mediawiki.org/wiki/Scrum_of_scrums/2016-09-28

= 2016-09-28 =

== Product ==

=== Reading ===

 Mobile Content Service (MCS) 
* Fixed video anchors
* No deploys this week due to ops offsite
* Starting discussions  versioning sections endpoint

 Android native app 
* Current sprint board: https://phabricator.wikimedia.org/project/view/2238/
* Next sprint board: TBA
* Navigation overhaul work for beta release is complete.  Release will go
out the door today (9/28).
** We'll likely promote to stable quickly if no significant issues emerge.

 Reading Web 
* Current sprint board:
**Begin rolling out wikidata descriptions to top 6 wikis
**Move Related Pages to stable mobile web Wikipedias (all but top 6)
**Investigate hovercards instrumentation issues around 9 Sep -
https://phabricator.wikimedia.org/T146620
*** Big drop in EL events in a few extensions -
https://phabricator.wikimedia.org/T146840

 iOS native app 
* Current release board:
https://phabricator.wikimedia.org/project/board/2220/
** 5.3 is in development
** Release date is expected to be before end of October
** WIll include migration to MCS feed endpoint

 Reading Infrastructure 
* blocking: TemporaryPasswordPrimaryAuthenticationProviderTest is flaky
https://phabricator.wikimedia.org/T146498
* blocked: nothing
* updates: last call for comments on the proposed api.php integration for
ORES and pageviews: https://phabricator.wikimedia.org/T143895
https://phabricator.wikimedia.org/T144865

=== Community Tech ===
* No blockers
* Moving CopyPatrol to French Wikipedia
https://phabricator.wikimedia.org/T145431
* Adding account creation to Striker
https://phabricator.wikimedia.org/T144710#2674663
* Updating CentralAuth tables for cross-wiki watchlist
https://phabricator.wikimedia.org/T142507 (Gerrit review needed:
https://gerrit.wikimedia.org/r/#/c/309553/ )
* Adding start/end times to WikiEd Programs Dashboard
https://phabricator.wikimedia.org/T125546
* 11-year old task to send a cookie with each block
https://phabricator.wikimedia.org/T5233
* Slowly deploying PageAssessments to English Wikipedia
https://phabricator.wikimedia.org/T146679

=== Editing ===
 Language (not present, only notes) 
* Blocked
** Would appreciate comments from ops or puppet-knowledgeable person how to
override restbase url in puppet for a service in labs
*** https://phabricator.wikimedia.org/T129284#2674533
*** The goal is to be able to text content translations on deployment-prep
with real articles from different wikipedias.
* Blocking: not aware

 Parsing 
* Tim working on updates to the parser tests infrasatructure (
https://gerrit.wikimedia.org/r/#/c/312969/3 and related )
* Scott continuing work on having Parsoid parse language variant markup
(close to moving out of WIP status)
* Planning to deploy Parsoid's native  implementation in a
backward compatible way and have VE pick it up when they are ready to use
it -- if it doesn't happen next week, it will only happen in 3 weeks time
(since we have parsing team and editing dept offsites starting oct 10).

 Collaboration 
* Blocked
** Continuing collaboration with Services team on ReviewStream
* Blocking
* Updates
** Will have a meeting with the Wiki Labels team on Friday to discuss how
we can collaborate
** Continuing work on Flow back-end, including caching refactor and bug
fixes for opt-in on user talk
** Continuing Echo work, including instrumentation to track the number of
page views before viewing notifications.

=== UI Standardization ===
* Working on
** Align Minerva (Mobile Frontend) to overhauled color palette:
MobileFrontendhttps://phabricator.wikimedia.org/T146799
** Review current style and integrate messages and message boxes as
MediaWiki UI component
https://phabricator.wikimedia.org/T127405
** MediaWiki theme: Use `color-progressive` for switched-on binary inputs
https://phabricator.wikimedia.org/T145629
* Finished
** Published new color palette https://phabricator.wikimedia.org/M82 with
WCAG 2.0 level AA compliant colors
** Button styles differ in mediawiki.UI from design templates and OOjs UI
https://phabricator.wikimedia.org/T146823
** Align Wikimedia Portal UI elements to improved color palette
https://phabricator.wikimedia.org/T146231


== Technology ==
=== Analytics ===
* Deployed new throttling limits to Pageview API, doing real well with
super low latencies, we will add capacity to double requests served next
week:
https://grafana.wikimedia.org/dashboard/db/aqs-elukey?from=1474479314693=1475084114695

* Erik Z vetting data from edit reconstruction project on simplewiki, after
edit reconstruction calculating metrics is much easier. We can calculate
metrics frm very beginning:
https://analytics.wikimedia.org/dashboards/standard-metrics/#simplewiki

* Load testing druid and about to put pivot in production accesible
internally to wmf, this is a UI to some of our data in hive, mostly
pageviews, no need to use sql

== Security ==
* Intake 

[Wikitech-l] CREDIT Showcase, Wednesday, 5-October-2016 - call for demos

[Adam Baso]

Greetings -

The next CREDIT showcase is Wednesday, 5-October-2016 at 1800 UTC (1100 San
Francisco).

https://www.mediawiki.org/wiki/CREDIT_showcase

We look forward to seeing your demos! Please add them to the Etherpad and
mark your calendars:

https://etherpad.wikimedia.org/p/CREDIT

We welcome works in progress and would be thrilled to see works from
Wikimedia community members, as well as staff.

If you missed last month's CREDIT, here it is!

https://www.youtube.com/watch?v=rfBQ6H14_SM=54

Finally, If you would like to invite anyone to CREDIT, feel free to use
this template.

*Hi *

*I hope all is well with you! I wanted to let you know about CREDIT, a
monthly demo series that we’re running to showcase open source tech
projects from Wikimedia Community, Reading, Editing, Discovery,
Infrastructure and Technology.*

*CREDIT is open to the public, and we welcome questions and discussion. The
next CREDIT will be held on October 5th at 11am PT / 2pm ET / 18:00 UTC. *

*Here’s a link to the YouTube live stream
, which will be available
shortly before the event starts. There’s more info on MediaWiki.org
, and on Etherpad
, which is where we take notes and
ask questions. You can also ask questions on IRC in the Freenode chatroom
#wikimedia-office (web-based access here
). *

*Please feel free to pass this information along to any interested folks.
Our projects tend to focus on areas that might be of interest to folks
working across the open source tech community: language detection,
numerical sort, large data visualizations, maps, and all sorts of other
things.*

*Thanks, and I hope to see you at CREDIT.*


   -

   *YOURNAME*




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

Re: [Wikitech-l] Code of Conduct

[Matthew Flaschen]

On 09/28/2016 07:07 AM, Steinsplitter Wiki wrote:

Last but not least: I am not happy at all that me comment has been
strike from
https://www.mediawiki.org/w/index.php?title=Talk:Code_of_Conduct/Draft=2247995=2247822
by Matt Flaschen (WMF). Looks like it is no longer allowed to comment
over there, thus i write here.


It had nothing to do with who made the comment, or your views on the 
section.


Rather, the issue is that you were taking a position in a discussion 
that was closed two weeks ago.  That could confuse people reviewing the 
discussion.


Matt Flaschen

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

Re: [Wikitech-l] Intro to "Committee" and "Diversity" section approved, "Conflict of interest" needs more work

[Matthew Flaschen]

On 09/06/2016 05:42 PM, Matthew Flaschen wrote:

The community approved the introduction to the Committee section
(https://www.mediawiki.org/wiki/Code_of_Conduct/Draft#Page:_Code_of_Conduct.2FCommittee)
(the part after "Committee" and before the "Diversity" section), as well
as the "Diversity" section
(https://www.mediawiki.org/wiki/Code_of_Conduct/Draft#Diversity).

There was not consensus to approve the "Conflict of interest"
(https://www.mediawiki.org/wiki/Code_of_Conduct/Draft#Conflict_of_interest)
section.  Work will continue on this section.  See the top of
https://www.mediawiki.org/wiki/Talk:Code_of_Conduct/Draft#Finalize_.22Conflict_of_interest.22_section.3F
(including the sections linked from those bullet points).


There has been further discussion on it, aiming to solve those issues. 
Please participate in the sub-sections of 
https://www.mediawiki.org/wiki/Talk:Code_of_Conduct/Draft#Finalize_.22Conflict_of_interest.22_section.3F 
and make sure your concerns are being addressed.


Thanks.

Matt Flaschen

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

Re: [Wikitech-l] Code of Conduct

[Gergo Tisza]

On Wed, Sep 28, 2016 at 4:07 AM, Steinsplitter Wiki <
steinsplitter-w...@live.com> wrote:

> Unfortunately, the whole Code of Conduct Voting hasn't been widely
> announced (just on phabricator).


By my count, Matt has sent over twenty announcements about it to this list
(and quite a few others) over the course of the last thirteen months.
The specific section you have commented on has been announced on July 26:
https://lists.wikimedia.org/pipermail/wikitech-l/2016-July/086151.html
and then again on August 24:
https://lists.wikimedia.org/pipermail/wikitech-l/2016-August/086357.html

See also the earlier discussion about where announcements should be made:
https://www.mediawiki.org/wiki/Talk:Code_of_Conduct/Draft#Wider_participation.2C_still


> I mainly see participation just from  a very closed group.
>

I don't think "closed" is a reasonable word to use there. Participation is
mainly from a small, self-selected group of people who chose to care. Most
discussions work like that. Compare the number of people who were involved
in defining Commons copyright policy to the number of people who upload
images, or the number of people who where involved in the discussion of the
(then) new Wikimedia-wide terms of content to the number of people who use
the site...

Last but not least: I am not happy at all that me comment has been strike
> from  https://www.mediawiki.org/w/index.php?title=Talk:Code_of_Con
> duct/Draft=2247995=2247822 by Matt Flaschen (WMF). Looks like
> it is no longer allowed to comment over there, thus i write here.
>

According to the current draft, there is an amendment process every three
months where details of the code of conduct can be rediscussed; I would
recommend aiming for that.

(Also, in my personal opinion, your comment might have been received more
kindly if it contained anything substantive, but it was just +1 to an
IDONTLIKEIT 
comment.
Those tend not to be helpful in a consensus-building process.)
___
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

[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

[Wikitech-l] Code of Conduct

[Steinsplitter Wiki]

Hello,

I am not sure where to ask, thus i write here. Sorry if this is the wrong place!
I noticed that a Code of Conduct for Phabricator is getting developed. Cool to 
see that people are creating such a policy, it is standard yet in big other 
projects. :-)

Just a few thoughts:
Unfortunately, the whole Code of Conduct Voting hasn't been widely announced 
(just on phabricator). There are a lot users which are using phab just once at 
year. Such a important decision should be widely announced imho. I mainly see 
participation just from  a very closed group.

Last but not least: I am not happy at all that me comment has been strike from  
https://www.mediawiki.org/w/index.php?title=Talk:Code_of_Conduct/Draft=2247995=2247822
 by Matt Flaschen (WMF). Looks like it is no longer allowed to comment over 
there, thus i write here.

:-)

Regards,
Steinsplitter



http://meta.wikimedia.org/wiki/User:Steinsplitter

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

Re: [Wikitech-l] Gerrit screen size

[Mukunda Modell]

If only we could plug in the gerrit back-end (via API) to the phabricator
front-end. Phabricator has a much better diff viewer and commenting
system.  Gerrit is superior in many ways but the UI is so terrible it's not
even funny.


On Tue, Sep 27, 2016 at 10:00 AM, Paladox 
wrote:

> Not really, since gerrit is a google owned project, and google supports
> most browsers, it is unlikely that Internet Explorer will never be
> unsupported in google projects unless no one uses ie or Microsoft drops all
> support for Internet Explorer.
>
> On Tuesday, 27 September 2016, 9:39, rupert THURNER <
> rupert.thur...@gmail.com> wrote:
>
>
>  Isn't Gerrit more for developers who as a consequence anyway run multiple
> browsers and therefore do not care so much that it does not support Ie?
> On Sep 26, 2016 20:14, "Paladox"  wrote:
>
> There new skin called polygerrit fixes all the issues described here. It
> is moving along greatly but it doesn't support all browsers yet, namely
> Internet Explorer due to polygerrit using es6 and internet explorer does
> not support es6. They are going to something in the q2 of next year work on
> internet explorer support, hopefully it will make it into gerrit 2.14,
> 2.15, and hopefully we will still be using gerrit then and update it and
> also hopefully polygerrit will have added all the missing features.
> Polygerrit is very responsive as I tried this on my mobile (iPhone) and it
> worked.
>
>
>
> On Monday, 26 September 2016, 18:39, Rob Lanphier 
> wrote:
>
>
>  On Sun, Sep 25, 2016 at 5:41 AM, Tim Starling 
> wrote:
>
> > On 25/09/16 21:09, Bináris wrote:
> > > I try to familiarize myself with Gerrit which is not a good example for
> > > user-friendly interface.
> > > I noticed a letter B in the upper right corner of the screen, and I
> > > suspected it could be a portion of my login name. So I looked at it in
> > HTML
> > > source, and it was. I pushed my mouse on it and I got another half
> window
> > > as attached.
> > >
> > > So did somebody perhaps wire the size of a 25" monitor into page
> > rendering?
> > > My computer is a Samsung notebook.
> >
> > In T38471 I complained that the old version was too wide at 1163px
> > (for my dashboard on a random day). Now the new version is 1520px. I'm
> > not sure if the Gerrit folks are serious or are trolling us. Perhaps
> > it is a tactic to encourage UI code contributions?
> >
>
> My suspicion is that the Gerrit folks (in particular, Shawn Pierce) aren't
> so much trolling us as saying "stop relying on the UI of Gerrit!  That's
> not the point!"  The last time I was paying close attention to this, Gerrit
> upstream seems to be particularly focused on building code review features
> suitable for:
> 1.  Incorporation into git upstream
> 2.  Integrated into development UIs like Eclipse
>
> The strategy seems to be "Gerrit is a reference implementation of a code
> review UI for Git".  I haven't paid close enough attention to either Gerrit
> upstream or Git upstream to know if the Gerrit core contributors have made
> progress in getting code review functionality added to Git core (or if
> they've given up, or if I completely misunderstood their strategy).  I'm
> guessing that Eclipse has pretty good Gerrit support, but I rarely play
> with Eclipse, so that's just a guess based on the Eclipse Foundation's
> involvement with Gerrit.
>
> As bd808 noted, Gerrit upstream seems to be working on yet another UI,
> which would make sense if their goal is to create a variety of compatible
> implementations of advanced Git functionality.
>
> Rob
> __ _
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/ mailman/listinfo/wikitech-l
>
>
> __ _
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/ mailman/listinfo/wikitech-l
>
>
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
___
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