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.

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

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?

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

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

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.

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.

@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 :)

In T147892#2890975, @srishakatux wrote:

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

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! :)

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

@Mglaser: Any reply?

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