Page MenuHomePhabricator

How to unleash the power of 3rd party extension developers
Closed, DeclinedPublic

Tokens
"Like" token, awarded by Tgr."Like" token, awarded by Kghbln."Like" token, awarded by Miriya52."Love" token, awarded by Samwilson."Like" token, awarded by Aklapper."Like" token, awarded by Bawolff.
Assigned To
Authored By
Mglaser, Oct 11 2016

Description

Session Title

How to unleash the power of 3rd party extension developers

Main Topic

How to grow our technical community

Type of activity

Unconference session

Description



=== 1. The problem ===

[[ #mediawiki-stakeholders-group | We ]] estimate that there are hundreds (if not thousands) of MediaWiki installations hidden behind firewalls which have custom extensions. However, the developers of these extensions do not have the resources or courage to publish their extensions and the developers of these extensions often follow their own coding processes.

This leads us to conclude that there is a lot of untapped potential for MediaWiki, both in terms of functionality and extensions.

[[ #mediawiki-stakeholders-group | We've ]] discussed this before (see our [[ http://mwstake.org/mwstake/wiki/MediaWiki_Usage_Report_for_Wikimania_2015 | MediaWiki Usage Report for Wikimania 2015 ]]). There is [[ https://www.mediawiki.org/wiki/How_to_become_a_MediaWiki_hacker#Submit_your_changes | documentation here about how to submit code ]], but it does not cover the case where extensions already exist for a particular cause and need to be freed or generalized.

=== 2. Expected outcome ===
- An initiative "Submit your MW code", which welcomes and mentors corporate MW developers
- A named group of volunteers willing to do so (possibly lead by #MWStake)
- An agreement on a structure within MW.o where corporate MW devs can go to and find help

=== 3. Current status of the discussion ===
See links listed below.
(If you want to discuss a specific aspect already covered by a task listed below, please use that task listed below. For general or high-level comments on recommending tasks that are suitable for new technical contributors, please use this very task.)


== Proposed by ==
@MarkAHershberger, @mglaser

== Preferred group size ==
15-30

== Any supplies that you would need to run the session ==
Post-its and markers

== Links ==
* {T653}

== Interested attendees (sign up below) ==
* @MarkAHershberger
* @cicalese
* @Qgil
* @Tgr

Event Timeline

Mglaser created this task.Oct 11 2016, 9:16 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptOct 11 2016, 9:16 PM
Isarra added a subscriber: Isarra.Oct 19 2016, 4:31 AM
Tgr added a subscriber: Tgr.Oct 31 2016, 4:11 AM

Currently if you host your code on gerrit there is a good chance that your extension will be at least considered before breaking core changes - core developers usually grep the extensions repo to see what effects a change will have. If you host it elsewhere, it will be invisible. That expectation is not well-advertised; it probably should be.

Mglaser updated the task description. (Show Details)Oct 31 2016, 8:04 PM

@Tgr, I agree. Also, automated testing in Jenkins has gone pretty far and should be utilized more by extension developers. It is a real benefit to know my extension code does not break current MediaWiki.

Mglaser closed this task as Declined.Nov 3 2016, 10:22 AM

Closing this as I will not attend the Summit.

Mglaser reopened this task as Open.EditedNov 4 2016, 3:24 PM
Mglaser reassigned this task from Mglaser to MarkAHershberger.

Reopening this as @MarkAHershberger can take over the session.

Qgil added a subscriber: Qgil.EditedNov 23 2016, 8:20 PM

Developers of these extensions do not have the resources/time/courage to publish their extensions

Will they have the resources/time/courage to maintain their extensions as free software projects, open to adoption by other users, which might very well bring compatibility problems, bug reports, feature requests, support requests...?

What I mean is, let's imagine that the barrier to publish an extension using the Wikimedia infrastructure would be trivial, and they publish their extensions. What comes next? Is it only the initial barrier what stops these developers to convert their currently proprietary and private extensions in public and freely licensed?

Tgr added a comment.Nov 23 2016, 8:34 PM

A less ambitious expected outcome could be clear and prominently linked documentation about the benefits and responsibilities of hosting your code in gerrit. It's quite possible most extension developers don't even realize it's an option.

This comment is somewhat tangential to the discussion, but is nevertheless relevant. This coming year, the Parsing Team is planning to develop a new parser hooks API that is implementation-independent and doesn't expose parser internals. So, the goal is to en masse deprecate all existing parser hooks and encourage migration and adoption of the new API. Towards that end, at least for extensions deployed on the Wikimedia cluster, I've collection information about used hooks here. The migration to the new parser hooks API would be trivial in most cases, but some extensions (ex: FlaggedRevs, Translate) might potentially require more work.

@Legoktm will be leading that effort with input from the rest of the team. But, input about how extensions are using tag hooks (for those that aren't used on the Wikimedia Cluster) would be good. I'm going to be publishing a wiki page with all of our upcoming plans and work for the coming year soon, but this is just an advance heads up.

I thought I would mention this in the light of what @Tgr added above about grepping code before making breaking changes.

I'm not sure what "a structure within MW.o where corporate MW devs can go to and find help" is and how the existing support mechanisms don't already cover it

Qgil added a comment.Nov 30 2016, 11:40 AM

@MarkAHershberger could you adress the questions or at least share your opinions, please? Especially if this session aims to be pre-scheduled, ongoing discussion before the event is important.

MarkAHershberger added a comment.EditedNov 30 2016, 4:44 PM

Krenair writes:

I'm not sure what "a structure within MW.o where corporate MW devs can
go to and find help" is and how the existing support mechanisms don't
already cover it

You're right, the resources are there for those who know how to find
them.

However, this ignores the mindset of many “corporate” workers on MW
since (from my experience in the MW Support Desk and with some actual
devs) they aren't there.

For example, as has already been noted here, a lot of work could be done
to make setting up a git repo as easy as it is on github. This, alone,
would encourage people who write code for their own wiki to participate
in the MW commmunity on MW.o.

So, how is "a structure within MW.o where corporate MW devs can go to
and find help" going to help?

Ideally, it should be simple and obvious from the front page of MW.o how
to contribute code and manage their site. From the front page of MW.o,
I can click “Become a MediaWiki developer” and I'm met with a wall of
text that, several paragraphs in, links to “Developer access” and then a
“Gerrit Tutorial”.

I'd like to suggest that we specifically target developers who maintain
an internal MW site from MW.o by addressing these devs on the front page
of MW.o — something like “Using MediaWiki for your organisation? — click
here for best practices!” (Note that these “best practices” should be
created in consultation with people who run large private wikis as well
as WMF devs — the cross pollination should be good for both sides.)

From there, we could write provide articles that are of specific
interest to people who run MediaWiki behind a firewall and begin to draw
them into the larger MW community.

(Aside from just the MW.o structure, organisational changes are needed
so that developers on core MW are aware of the community outside of WMF
projects that uses their code and their use cases.)

@Qgil: had most of this written yesterday… sorry for taking so long.

Kghbln added a subscriber: Kghbln.
Qgil updated the task description. (Show Details)Dec 1 2016, 8:58 AM
Qgil moved this task from October to December on the Developer-Advocacy (Oct-Dec-2016) board.
Qgil added a comment.Dec 2 2016, 9:01 AM

In terms of room capacity and configuration, what would be your preference?

  • The biggest room in theater configuration (up to 200 people, only chairs, no tables) and required video recording (meaning also that people have to wait for the mic to speak etc).
  • A big room in classroom configuration (up to 70-80 people, chairs and tables) and required video recording (meaning also that people have to wait for the mic to speak etc).
  • A big room in classroom configuration (up to 70-80 people, chairs and tables) and optional video recording (i.e. only recording the initial introduction but then relaxing things during the discussion, or no recording at all).
  • A smaller room, flexible configuration, optional video recording...

@Mglaser @MarkAHershberger Hey! As developer summit is less than four weeks from now, we are working on a plan to incorporate the ‘unconference sessions’ that have been proposed so far and would be generated on the spot. Thus, could you confirm if you plan to facilitate this session at the summit? Also, if your answer is 'YES,' I would like to encourage you to update/ arrange the task description fields to appear in the following format:

Session title
Main topic
Type of activity
Description Move ‘The Problem,' ‘Expected Outcome,' ‘Current status of the discussion’ and ‘Links’ to this section
Proposed by Your name linked to your MediaWiki URL, or profile elsewhere on the internet
Preferred group size
Any supplies that you would need to run the session e.g. post-its
Interested attendees (sign up below)

  1. Add your name here

We will be reaching out to the summit participants next week asking them to express their interest in unconference sessions by signing up.

To maintain the consistency, please consider referring to the template of the following task description: https://phabricator.wikimedia.org/T149564.

Qgil added a comment.Dec 20 2016, 10:58 AM

@MarkAHershberger This session hasn't been pre-scheduled. The competition for slots was tough and there hasn't been much activity here.

Are you still interested in running an Unconference session? If so, please follow @srishakatux's instructions above. Otherwise, we can morph this into an online discussion with the same expected outcome defined in the description.

@Qgil, I meant to do this last weekend. Thanks for the reminder.

@MarkAHershberger double checking to see if I understood right :) if you are interested in running this as an unconference session, then check my comment here: T147892#2878747 and edit the task description by referring to the template of the following task description: https://phabricator.wikimedia.org/T149564. Thank you :)

MarkAHershberger updated the task description. (Show Details)

edit the task description by referring to the template of the following task description: T149564

Thanks for providing an example and your patience.

To the other people who've shown interest in this, please edit the task description and add yourself under "Interested attendees".

cicalese updated the task description. (Show Details)Dec 22 2016, 6:05 PM
Tgr awarded a token.Dec 23 2016, 1:40 AM
Tgr updated the task description. (Show Details)Dec 23 2016, 1:59 AM

To the facilitator of this session: We have updated the unconference page with more instructions and faqs. Please review it in detail before the summit: https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit/2017/Unconference. If there are any questions or confusions, please ask! If your session gets a spot on the schedule, we would like you to read the session guidelines in detail: https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit/2017/Session_Guidelines. We would also then expect you to recruit Note-taker(s) 2(min) and 3 (max), Remote Moderator, and Advocate (optional) on the spot before the beginning of your session. Instructions about each role player's task are outlined in the guidelines. The physical version of the role cards will be available in all the session rooms! See you at the summit! :)

Qgil added a comment.Jan 24 2017, 10:52 AM

@MarkAHershberger do you want to reuse this proposal in some form, i.e. a Tech Talk?

Qgil writes:

@MarkAHershberger do you want to reuse this proposal in some form,
i.e. a Tech Talk?

Since I was going to use @Mglaser's idea (and became too busy), I think
he should answer that.

@Aklapper, @Qgil, while I think the topic is still relevant, I think if I or someone else reuses the proposal, we can open an new task. I don't have any near term plans to reuse it, so the task can be closed.

Qgil closed this task as Declined.May 8 2017, 1:13 PM