Topic on Talk:Wikimedia Developer Summit/2017

On wikitech-l, @Brion VIBBER wrote "Opening up MediaWiki dev summit in January?" :

The last couple years we've done a big MediaWiki Dev Summit in January,
around the time of the Wikimedia Foundation all-hands meeting. Invitations
have been fairly broad to known developers, but there's a very strong
feeling that newbies, non-technical people, and in general *the people
MediaWiki is created and maintained for* are not welcome.

I think we should change this.

I would really like a broader MediaWiki Dev Summit that asks our users to
participate, and asks "developers" to interact with them to prioritize and
work on things that really matter to them.

I want template authors, Lua module authors, template users, power editors,
folks working on the lines of defense for vandalism patrol and copyvio
checking. I want people with opinions on discussion systems. I want people
who have been editing for years and have experience with what works and
what doesn't. I want people who wish they could edit but have a bad
experience when they try, and want to share that with us so we can help
make it better.

Thoughts?

-- brion

Much more conversation on the thread. I'd like to move that conversation to this wiki.

Thanks to RobLa for posting this, I would not have been aware of it. Thanks to Brion for bringing the subject up.

I've been made aware of this summit by a post on the MediaWiki-Distributors mailling list. I'm interested in participating but uncertain as my involvement in MediaWiki related things are low. A few years ago, I did dip my toe into some dev efforts surrunding MSSQL, LDAP and SemanticMediawiki. I got access to gerrit as well as the WMFlabs infrastructure and was able to propose a few patch and work in bugzilla. It just a little before the big switch to Phabricator. That change to Phabricator and all the changes surrounding it got the better of me and I gave up at that time. Today still, I'm struggling with new development efforts introduced after that switch (Composer, Lua and others) and keep myself on the LTS.

In any case, here is some suggestion of topics you could discuss (keep in mind, it's only suggestion and I've been out of the loop since a while).

• Difficulties of integration of MediaWiki Core, Semantic MediaWiki and WikiData. WMF is not using Semantic MediaWiki and focus mostly on WikiData. Although a lot of effort is made by peoples behind Semantic MediaWiki, I find still find it hard today to figures the where and what when you try to mix it all together. All by themself the blocks are well documented and easy to find, it's mixing it up that it. Why has Semantic not been adopted more broadly? What is the main difference between SemanticMediaWiki and WikiData? Was there too much effort duplicated?
• Recently there has been some developpment around Microsoft SQL support. Microsoft and others has shown a lot of interest and put a lot of effort into pushing the MSSQL Database implementation. I do have some interest into and I believes peoples are forgeting an very viable and forgotten alternative that is FreeTDS and Extension:MSSQLBackCompat. How can MSSQL support be brough into the mix while keeping the later able to run? And why is effor on MSSQL on Windows take so much place while MSSQL on Linux (thought FreeTDS) is pushed away? The main Databases classes are for heavy use and have a lot of code, is there a way to have a faster, easier and dummer Database class that would bring content into the wikitext and not have to worry with the whole compatibility with the main one?
• Speaking of Database, my feeling is peoples seem unaware of using two Databases drivers at the same time, yet that is a fantastic feature and I use in my own private instance to fetch data from outside the wiki tables. For example, my main Database driver is MySQL like almost everyone yet my MediaWiki instance does run query into some MSSQL Database through the previously mentionned extension.
• Speaking of content brought in from external source, I know there is a lot of talk this year about something else than text/plain or text/wikitext. What about pulling data from entreprise dashboard, external event, bus system, other database and what not? What could be done in the back end to bring more datasource to the rendering and parsing engine? What about pushing it back? What about readonly backend while the wikitext remain readwrite?
• Regarding developpement tools and WMF processes. Lately the foundation have got a lot of new toys and improvement around the developpement process. Those involved in those processes on a daily or weekly process can follows it with some easy but, in 2012, I felt the bar to contribute was quite high. Today, as a casual hacker, I don't see the bar anymore and I'm overwhelm with resuming any work within the source code.
• As a Debian user, the packaged version of MediaWiki is 1.19 and therefore it is still part of my work to work against the 1.19 code base. As you can imagine this is very hard to approch the new concept while still being dragged by use way of working from 1.19 era. What could be done to help package or be packge friendly? Why caused such a lag behind? There is bring new on this issue though, the lastest and newest is starting to appear on Debian due to some amazing work from many developers that tackle that issue and I'm looking forward to Debian 'Stretch' with MediaWiki 1.27!
• My use case of MediaWiki is behind a private firewall and therefore face some different challenge than WikiMedia. I believes most devs are familiars with those use cases as there was many presentation in years piors about use of the MediaWiki software elsewhere. But what is the future for them? Is there a middle ground between the CIA super isolated MediaWiki and the public non-WikiMedia MediaWiki server that use and consume contents from Commons and WikiData? What about two private users sharing between each others insteads? A 'Common' outside Commons and the public web but still sharable between two instances? What about sharing Template? Pulling the amazeball templates from Wikipedia and pulling it it? What about a better starting wikitext database with those fancy things peoples think for granted in Wikipedia but is not so easy to build from scratch? Available so close, right at your finger tips but it's breaking like choas so easily in your private instead?

Thanks you to all the devs for this amazing software even though my tone might have not appear cheerful in the previous comments, rest assured that MediaWiki's code base still amaze me everything I look at it. It's a fantastic endeavour and I'm very grateful for everyone's contribution to it. I'm cheering for your success! (sorry for my bad English, it's not my native language)

Given that there's already an active discussion on the mailing list, I don't see why we'd want to move it over to the wiki. I think moving it would just be disruptive to the productive (IMO) conversation that's already happening.

The reason for having the conversation here is because we can document and keep track of our conversation much better here than on the mailing list. It's a lot easier to link newcomers to a portion of the conversation, and broaden the conversation beyond just the mailing list.

It seems that it has been decided that attendance at this invitation-only event is restricted to "Wikimedia technical contributors and third party developers using the Wikimedia APIs or MediaWiki". That seems like a missed opportunity. It would have been preferable to consider how best to obtain input directly from users (readers and constributors) rather than through the necessarily restrictive lens of surveys, and to engage directly with their needs, expectations, concerns and wishes. It would also have been preferable to engage with community leaders who can engage on the subject of mismatch between community policies and developer initiatives (such as we saw with respect to the failed Gather initiative). I do not propose a specific mechanism here, and time may not be sufficient to resolve the issue in time for the 2017 meeting, but propose that this issue should be explicitly discussed at the Summit itself with the aim of developing proposals that would make for a more effective meeting in 2018.

On the contrary, there was a lengthy discussion in wikitech-l about opening the Summit to other profiles beyond developers, including users. Anyone involved in technical collaboration is a technical contributor, not just developers. Facilitators of the different main topics are being encouraged to reach out to the different stakeholders in their areas, beyond the usual suspects.

If you or someone you have in mind should be at the Summit, please (tell them to) request an invitation.

"On the contrary" to what? I quoted directly from the main page for this event for which this is the discussion page. Is that page wrong?

On the contrary to "It seems that it has been decided that attendance at this invitation-only event is restricted to". The event is a Developer Summit and the target participants are all Wikimedia technical contributors and third party developers using the Wikimedia APIs or MediaWiki. Users participating in the planning, development, testing, documentation, deployment, etc, of technical projects are technical contributors. We haven't declined the participation of any user requesting it.

At the same time, we don't want to mislead users potentially interested in this event. This is not Wikimania, and it is not intended to be.

The only sentence describing the invited attendance at this invitation-only meeting is "We welcome all Wikimedia technical contributors and third party developers using the Wikimedia APIs or MediaWiki." If it is intended to welcome some other groups, then perhaps a description of those other groups could and should be added to the main page. It is far from clear to me that "technical contributor" refers, for example, to a reader or content contributor with a request or requirement for new or improved forms of content presentation. Such a person would not regard themselves as a Developer, and is not likely to regard themselves as a natural fit for an event billed as a "Developer Summit" which is described as "invitation-only". If you mean that users interested in engaing with developers in the "planning, development, testing, documentation, deployment, etc, of technical projects" are intended and welcome invitees, then you need to say so. It is not really satisfactory to argue that people who are not obviously included in your invitation should somehow guess that they are in fact welcome to apply if they are not included in the "welcome" category.

OK, you are right. Is this better now?

Thanks.