@Rfarrand: Which project tag should be associated to this task? International-Developer-Events ? Something else? TIA

I know it's early but Can I suggest talks are livestreamed out?

I'd like to request that the relationship between the MediaWiki software (and supporting services like Parsoid/VE, etc) and the communities using the software like the WMF (as an org), Wikipedia projects, Wikipedia supporting orgs, and enterprise/3rd-party users be formally discussed and organized. Considering the level of work going on to restructure so much regarding the software, this is the time to formally discuss and decide the details, policies, and priorities of these relationships. Maybe the result is that the MediaWiki Stakeholders and/or some new organization formally take on some level of responsibility based on a Memorandum of Understanding between the WMF, Wikipedia orgs, and enterprise/third-party users. Ideally we all come to some kind of agreement now instead of later in order to make better decisions early on in the restructuring (based on the strategic goals).

In support of this topic, please check out the panel discussion filmed just last week: https://www.youtube.com/watch?v=GjUGyd8jJCo - I think the panelists touched on some of the factors, but there's obviously lots more to discuss.

Since not everyone can attend WMTC19, would it make sense to set-up a meeting with the WMF and 3rd party users of MediaWiki (mwstake, etc.) to discuss the strategic goals and how the software might change if those goals are realized? If the first meeting is successful, it might make sense to continue these meetings at some reoccurring interval, in general this would probably keep the conversation going between TechCons.

For reference, the idea of a special interest group periodically meeting was mentioned in https://www.mediawiki.org/wiki/Wikimedia_Technical_Conference/2018/Session_notes/How_do_we_work_together#3rd_Party

Given this is the Wikimedia tech conference, I wouldn't consider central working on defining the relations between the Wikimedia movement and third-party users of Wikimedia products. I'm not against having it as a theme, but it's by far not the first thing I would talk about.

Judging from questions that get asked repeatedly in tech discussions within and around TechCom, we have some large themes that need discussion from the technical point of view, which are at the very least:

• Frontend and edge architecture evolution - we need to evolve how our frontend is built to make it more versatile and adaptable, and as a consequence we need to discuss such topics as what technologies we want to use, how (and if) to separate the frontend rendering from the backend, how (and if) to do frontend composition
• Data storage interfaces - we need to come to agreements about what data storage interfaces we want to support in the future, from MediaWiki and other softwares, how to store safely and properly non-wikitext data in articles, etc.
• Inter and intra-wiki dependency tracking and change propagation: while the jobqueue is now solid and stable, we have some scalability issues with the largest exported resources, like wikidata's, and with circular dependencies in jobs like refreshLinks that are our biggest long-term scalability challenge. We need to have a better mechanism that what we have now to reduce the amount of redundant/useless jobs we run.

to which I'd add one topic that is important for the Wikimedia work of moving MediaWiki to a containerized environment, so a personal interest:

• How to rethink the way we deploy and release MediaWiki

I think the first three themes are pretty fundamental and should be part of the conference topics.

If further elaboration is needed, I'm happy to help.

Participants selection should be based on need and not on a fixed quota of participants.

It's extremely sad and frustrating we can't have a all-technical sit-down of any form with all the interested engineers in the movement.

To be clear: the three topics I named above have such a vast impact across the org that I dont' see 50 people tackling them in a satisfactory way.

We also need to bridge the gap between frontend and backend people.

We really need more than 50 participants this year, I would imagine 100 would be better. I would assume we'd select people based on core competencies and relevance to the topics to be discussed, not based on blind-copy essay writing. I would assume teams will choose the people who would represent them best to apply to the conference.

So my suggestion for the selection process is: select more people, and select on competencies, not blind measures. This will still make people feel excluded, but at least it would be a fair and non-subjective way to evaluate relevance.

I second the suggestion on the data storage interfaces, especially as MCR and Commons Structured Data go full steam ahead.

As far as attendance: Small groups may be able to be more focused, but large groups can be split into smaller groups. I would err on the side of having a few more people than is necessary, rather than too few. In the future we need to learn how to get the same work done via a combination of smaller regional events, but that's a complex topic to be discussed elsewhere.

Not everyone needs to be the expert in one of the topic areas in order to be selected to go. Having a few sets of fresh eyes / perspectives can be helpful. With that caveat, I agree generally with Joe's comments above about the selection process.

In T220212#5171872, @Joe wrote:

Participants selection should be based on need and not on a fixed quota of participants.

It's extremely sad and frustrating we can't have a all-technical sit-down of any form with all the interested engineers in the movement.

To be clear: the three topics I named above have such a vast impact across the org that I dont' see 50 people tackling them in a satisfactory way.

I agree, if we add that to the limited number of wmf staff for other conferences (hackathon, wikimania etc), there could be people who might fail to attend all of those:/
Moreover, we simply need a little more time together anyway.

We also need to bridge the gap between frontend and backend people.

+1 A problem that exists in many orgs already

We really need more than 50 participants this year, I would imagine 100 would be better. I would assume we'd select people based on core competencies and relevance to the topics to be discussed, not based on blind-copy essay writing. I would assume teams will choose the people who would represent them best to apply to the conference.

So my suggestion for the selection process is: select more people, and select on competencies, not blind measures. This will still make people feel excluded, but at least it would be a fair and non-subjective way to evaluate relevance.

+1, and also reserve some spots for newer people. A person joining the foundation in Sept, will have 0 chance of joining wmtc since they technically will have nothing to offer. On the other hand, they'd have everything to gain since they will meet their new colleagues and meet the foundation itself.

In T220212#5171931, @jijiki wrote:

+1, and also reserve some spots for newer people. A person joining the foundation in Sept, will have 0 chance of joining wmtc since they technically will have may have nothing to offer. On the other hand, they'd have everything to gain since they will meet their new colleagues and meed the foundation itself.

This is a concern I raised over and over in the past, too.

+1 on making the conf more inclusive

+1 to what @Joe said, and to what @jijiki said. Especially speaking as someone who has been at the Foundation only six months now.

+1 to @Joe

Thanks everyone, I will make sure these comments get onto the agenda for the next TechConf program committee (PC) meeting and ask that the PC communicates back onto this task around everything. :)

I agree that the relationship between the software and its users is not the priority of this conference, but I do think it is relevant. Since it is easy and obvious for this group to dive into deep technical issues, I just wanted to put the idea out there that some form of discussion of this relationship would be helpful, even if it's a single topic "on the side". I imagine there might be a large gap in technical understanding between the software developers who really understand the guts of the software and how it should change compared to the end users who only understand "user stories".

So one topic that might be relevant for this side discussion would be how these technical changes that are being formulated, decided, and implemented are conveyed to end users so they can weigh in on how that will impact their use cases (both good and bad). I think the foundation already has people who do this for the Wikipedia users, but I think there is room for improvement on how this is handled for other users of the software who might have useful feedback for how these changes might impact their use. I think there is also room for improvement on how feedback from these "user stories" is fed back into these technical decisions early enough in the process so they are being considered.

Hey All,

Thank you all for the suggestions so far! We appreciate them and we are happy to see so many people engaged and contributing so many good ideas and thoughts for the upcoming Technical Conference.

Please take into account that the coming Conference is about Developer Productivity and you can find the vision statement of the conference in the following link: https://www.mediawiki.org/wiki/Wikimedia_Technical_Conference/2019

We would appreciate it if the suggestions you have would fit the goals we wish to achieve from the coming conference. We believe that there are a lot of topics worth discussing, but we also value focus and this year we want to focus on ways to solve Development Productivity as a main general topic.

If your suggestion doesn’t fit the goals we have written down - no worries! We will have time for on-the-spot participant organized unconference during the event, to allow for discussions to flow and happen organically and to allow for other things to be touched upon.

Thanks in advance,

Technical Conference Program Committee

One of my hopes is that people will be concentrated together on topics. I'd prefer single track with a well structured format if at all possible.

If it can be arranged, I would probably suggest some actual trainers be procured for the event as well. We're a smart group and are experts, but I think could benefit from some external expertise that also excels in training. Those experts need to understand our problems, direction, and so on, so that it's not just generic training or overly specific but off topic training.

These ideas aren't revolutionary or even novel, but I don't see them explicitly mentioned, so here goes...

This topic came up in the hackathon last weekend (see T223607), but it bears repeating in terms of developer productivity: getting your code reviewed can be really hard. Issues touched on in the discussion at the hackathon include the disagreement about the purpose of code review, issues of code quality from new contributors, the relatively low number of new non-staff contributors, diffusion of responsibility for doing reviews, lack of time even when responsibility is clear, and the difficulty for new contributors to become productive—all the old favorites. I got a taste of the difficulty new non-staff reviewers must face when I worked on a 10% project outside of my team's scope that did not have a clear owner—it took me months to get reviews, though it did eventually happen.

Another big concern I've run into myself is stability of our development environment. Every so often there's an update to vagrant that breaks it (if you have just the right combination of things enabled). Since not everyone updates regularly, and the pool of developers using my exact combination of settings and roles may be as low as 1 (just me!), it can take a while to figure out the problem or for it to be resolved by updates. Things are further complicated by the fact that updating vagrant may break it, while re-installing from scratch may work. That's a very time-consuming process. My first or second week at the Foundation vagrant was broken and many people were at Wikimania, so I re-installed it several times trying to figure out why I couldn't get it to work. Eventually a fix came in and suddenly it just worked again. I've lost many hours to updating and re-installing vagrant. Something that was more stable and/or regularly tested for stability would be very helpful.

Another thing that I think the our team has done well—largely thanks to @dcausse—is making time to pay down technical debt. It's a gift to the productivity of future developers, sometimes including yourself.

In T220212#5204632, @dr0ptp4kt wrote:

One of my hopes is that people will be concentrated together on topics. I'd prefer single track with a well structured format if at all possible.

I would like to get people together to solve specific problems they have, in smaller groups of interest.

If it can be arranged, I would probably suggest some actual trainers be procured for the event as well. We're a smart group and are experts, but I think could benefit from some external expertise that also excels in training. Those experts need to understand our problems, direction, and so on, so that it's not just generic training or overly specific but off topic training.

The techical conference is (was?) a place to discuss the technical challenges ahead of us. Not a place where someone should come to deliver trainings, IMHO. Other venues would probably be more appropriate for that - I'm thinking a training track around hackathons is probably a better fit?

In T220212#5185070, @RazShuty wrote:

Hey All,

Please take into account that the coming Conference is about Developer Productivity and you can find the vision statement of the conference in the following link: https://www.mediawiki.org/wiki/Wikimedia_Technical_Conference/2019

We would appreciate it if the suggestions you have would fit the goals we wish to achieve from the coming conference. We believe that there are a lot of topics worth discussing, but we also value focus and this year we want to focus on ways to solve Development Productivity as a main general topic.

So, first of all, when I commented it wasn't clear to me that this conference would be so focused. So I'm sorry if my comments were off-topic. I think those are fundamental problems we have to engage on.

Still, I have a proposal that is fiddling in my head for some time and I want to formalize a bit better, that goes decidedly in the direction of developer productivity:

Self-service stateless microservices: Right now any new service needs to go through a series of steps to get in production, which make sense for long term projects but not for epxeriments or small services that just transform data from one source and are not in the critical path to serve the wikis. For such smaller projects, we could think of creating an ever more streamlined system that our current one, basically allowing people to register lambda services to an API to run in production in a self-service fashion. Such a system would allow much faster experimentation and iteration, but will need to be well defined and scoped. I think the conference would be the perfect place to have a discussion where we can better define the scope of such a project and gather requirements from people that could use it.

Expanding on my previous point, which I think is also relevant to the conference topic:

• How to rethink the way we deploy and release MediaWiki

I think is tied a lot to the topic of developer productivity. Right now, what we deploy in production is a binary blob that is a collection (done in-production) of various git repositories, and we deploy it via rsync, sometimes even syncing individual files.

Now, there are many issues with this, but most importantly:

• there is no real correspondence between the setup of code a dev can have on their machine and what's in production
• the dev env can't resemble the production environment even remotely

We want to be able to have a consistent experience between development and production with the only component changing being the configuration. We're already working on creating docker images to run MediaWiki locally for developers, we need to coordinate that effort with the one to run MediaWiki in a containerized environment in production. A base step to get there is to rethink how we deploy MediaWiki and how we organize code for production.

One more thing that frustates me a lot (and directly pays in into the developer Productivity vision in my opinion) is, that MediaWiki makes it complicated to run tests for people who didn't know how it's done specifically in MediaWiki. Like phpunit tests. You can't run them out of IntelliJ at all (as far as I know, I'm not sure how this is in other IDEs) and you can't run them easily with the default phpunit commands (which you may know from other PHP projects already). So a new MediaWiki developer needs to go through a lot of documentation first in order to know how to run tests.

However, running tests should be an integral part when developing software and therefore should be easily doable and preferably possible to do out of my preferred IDE. So we should think about technical changes to our infrastructure and code that:

• Makes it easier for newcomers to use the knowledge from other standard-PHP projects
• Does not break the workflow of established community-developers and our CI

@Florian I agree; check out https://gerrit.wikimedia.org/r/c/mediawiki/core/+/513106 for some exciting progress on these issues.

In T220212#5209716, @Joe wrote:

Still, I have a proposal that is fiddling in my head for some time and I want to formalize a bit better, that goes decidedly in the direction of developer productivity:

Self-service stateless microservices: Right now any new service needs to go through a series of steps to get in production, which make sense for long term projects but not for epxeriments or small services that just transform data from one source and are not in the critical path to serve the wikis. For such smaller projects, we could think of creating an ever more streamlined system that our current one, basically allowing people to register lambda services to an API to run in production in a self-service fashion. Such a system would allow much faster experimentation and iteration, but will need to be well defined and scoped. I think the conference would be the perfect place to have a discussion where we can better define the scope of such a project and gather requirements from people that could use it.

I love this idea, and I'd be eager to help develop it further.

Frontend and edge architecture evolution - we need to evolve how our frontend is built to make it more versatile and adaptable, and as a consequence we need to discuss such topics as what technologies we want to use, how (and if) to separate the frontend rendering from the backend, how (and if) to do frontend composition

+1!

A person joining the foundation in Sept, will have 0 chance of joining wmtc since they technically will have nothing to offer.

I think that the perspective of how easy or difficult it is to start contributing is a useful one to provide in itself. This contrasts well with attendees who are MediaWiki experts and may have different tooling expectations. It would be nice to discuss how we can make our code repos less surprising. Since MediaWiki is a unique platform, developers new to the movement (regardless of their experience elsewhere) may struggle with basic setup.

Frontend architecture evolution

+1

Additionally I would love to talk about couple things:

• adding build steps to both frontend and backend. Many modern frameworks provide a build step, that can perform many actions (like building the routing array)
• the CI infrastructure and the way how we handle testing. Automated testing is very important, but our stack grew a lot, running full suite of tests takes ages on dev machines, and like 30-50mins via CI.
• with a build step, we could use things like TypeScript which are super useful when developing big Javascript apps

In T220212#5171872, @Joe wrote:

Participants selection should be based on need and not on a fixed quota of participants.

It's extremely sad we can't have a all-technical sit-down of any form with all the interested engineers in the movement.

We also need to bridge the gap between frontend and backend people.

We really need more than 50 participants this year, I would imagine 100 would be better. I would assume we'd select people based on core competencies and relevance to the topics to be discussed, not based on blind-copy essay writing. I would assume teams will choose the people who would represent them best to apply to the conference.

I think that finding ways to collaborate on technical discussions + decisions remotely is a real challenge for productivity, continuity, clarity. So working on making events like these better for a larger audience of remote participants, like improving the code contribution process, seems relevant to the overall focus. OpenCon is a nice model, though less technical, for practical and decentralized collab on a fixed set of dates.
(Noms would still be needed for invites to a physical gathering, but now they could prioritize a mix of newcomers and old hands, to improve social links, not just immediate technical needs)

Wikimedia technical events like the developers meetings (hackathons) and the summit always had a strong MediaWiki and MediaWiki extensions focus. Less attention was given to the development happening on top of that. A lot of attention for the things happening behind the API, but not a lot on the consumers of the MediaWIki API (and the databases in case of the API not being sufficient). So maybe for this event in the selection process get some (heavy) consumers involved? I would look in the corner of bot and tool developers. This shouldn't be done if it waters down the scope too much or the group would become too large. Focus is important for this event to be successful.

In T220212#5258477, @Sj wrote:

In T220212#5171872, @Joe wrote:

Participants selection should be based on need and not on a fixed quota of participants.

It's extremely sad we can't have a all-technical sit-down of any form with all the interested engineers in the movement.

We also need to bridge the gap between frontend and backend people.

We really need more than 50 participants this year, I would imagine 100 would be better. I would assume we'd select people based on core competencies and relevance to the topics to be discussed, not based on blind-copy essay writing. I would assume teams will choose the people who would represent them best to apply to the conference.

I think that finding ways to collaborate on technical discussions + decisions remotely is a real challenge for productivity, continuity, clarity. So working on making events like these better for a larger audience of remote participants, like improving the code contribution process, seems relevant to the overall focus. OpenCon is a nice model, though less technical, for practical and decentralized collab on a fixed set of dates.
(Noms would still be needed for invites to a physical gathering, but now they could prioritize a mix of newcomers and old hands, to improve social links, not just immediate technical needs)

It has been proven over and over (see for instance the essay by Biella Coleman in the topic) that in-person gatherings at conferences are vital to the good functioning of a free software community that works remotely.

I find it hard to understand why we deprived our technical community of the possibility to meet in large numbers at least once a year. It's detrimental to morale, inter-team and inter-org collaboration, and overall is exclusive and will keep reiterating the current hierarchies (as new people will have a harder time getting to the conferences).

So, I don't think "better remote participation" is really a solution. We work remotely all year, we should invest money in having all (or most of) the development community meet in a single space at least once a year.

I would also like to know what will be the number of engineers that will be admitted to this event.

In T220212#5260551, @Multichill wrote:

Wikimedia technical events like the developers meetings (hackathons) and the summit always had a strong MediaWiki and MediaWiki extensions focus. Less attention was given to the development happening on top of that. A lot of attention for the things happening behind the API, but not a lot on the consumers of the MediaWIki API (and the databases in case of the API not being sufficient). So maybe for this event in the selection process get some (heavy) consumers involved? I would look in the corner of bot and tool developers. This shouldn't be done if it waters down the scope too much or the group would become too large. Focus is important for this event to be successful.

Please nominate them ;)

Additionally to what @Joe says we have gone all-in in past years on "better remote participation" putting more resources into it than we would be able to budget-wise / personal-wise this year. We streamed every single session. Paused every session for remote comments. Had an online moderator who was just meant to help participation of remote people, have remote advocates in sessions dedicated to making sure remote people had space. We advertised this all over the place in advance of the event like crazy. Almost nobody participated and most sessions had zero-1 remote participates.

From my experience with that and other events, remote conferences would be better when everyone is remote. In person conferences should focus on the people that are there but spend a lot of time gathering input in advance from people who are not attending and reporting out clearly giving people who did not attend the chance to read the outcomes and have input / impact on them before any of it is final-final.

As for the attendee caps and budget amounts @Joe that is something you should talk with c-levels about. Maybe at a staff community time, or in person, by an email. The program committee / folks following this thread do not impact that and is generally formed after the budget and attendee cap is finalized by finance / c-levels.
Additionally when the event has been much larger a very common theme and point of feedback in our feedback surveys is that it is imposible to have a conversation with to many people in the room. The current approach is more about having smaller conversations in smaller groups and not talk about everything at once.

I think you would be welcome to be involved in more heavily debriefing this years conference and making suggestions for future iterations if you attend and can find a few hours / some space in your schedule to attend some of those meetings. Personally, I would really be happy for that and to talk through solving some of these points with you.

Additionally when the event has been much larger a very common theme and point of feedback in our feedback surveys is that it is impossible to have a conversation with too many people in the room.

Let me add to that, that as far as I'm aware, that was feedback on the Architecture summit/Developer Summit as a 'decision making event'. A larger developer conference like Joe seems to be referring to (and of which I personally am also an proponent) more in the style of other large developer conferences would possibly have different feedback, because the initial goals and expectations would be different.

It is my opinion that a larger event is desirable, but it would probably require a huge amount of external funding, which due to our non-commercial ethos, lack of reach within other commercial organisations (as compared to Java or PHP for instance), as well as having to fly in so many people can be difficult to organise. This combined with Wikimania + All hands + Team Offsites + EU hackathon + this event, makes it hard to carve out the space for such a massive new event.

But next to the cost and time, we need to remember that most readers/writers/moderators have VERY few major events as well. By nature, we do not operate in ideal situations in that regard. Any good plans -> C level ;)

Some more potential topics:

Documentation and support channels: most of our repos have a decent amount of inline documentation and low-level on-wiki documentation, but very little high-level docs (architecture overview, explanation of design decisions, even changelogs are pretty rare). There is very little organizational focus on documentation, even though it's one of the big Platform Evolution goals - to the extent documentation happens, it happens because some team or volunteer (or maybe reviewer) cares about it, but if they don't, no one on a higher level will. There is minimal investment into professional documentation writer (I think we have one, for 100ish engineers; in other organizations 1:10 is typical), not much investment into documentation infrastructure (e.g. mediawiki.org), and not much organizational buy-in into initiatives like the documentation day (we had one, it was well-received, then never repeated). Our support channels are not inclusive, both due to poor usability (IRC, plaintext email or wikitext) and due to lack of good tools to handle tone and similar problems, and they make it hard to find relevant requests or responses.

Code review: @TJones already mentioned this, but it's probably our largest problem today. Code review for code that another team or volunteer is not actively working on tends to take months at best. There are no incentives for staff members to do code review (not even for code review of other staff, due to the restricted annual review format, much less for volunteers), while spending the same time on e.g. a side project will much more likely result in that work being celebrated. There is (at least in theory) 10% of paid engineering staff time set aside for experimentation, but 0% for supporting volunteers who write code. We use an older version of Gerrit which makes reviews of complex patches challenging to follow.

@Rfarrand I am having some more concerns than just the possibility of being unable to attend a certain event.
While we are a 26+ people team (~1/4 of Technology if I am not mistaken), for 2019:

• 0 SREs at the Hackathon '19 in Prague
• 2 SREs at Wikimania '19
• Based on last year, there will be probably 2 SREs at Techconf '19

In other words, it looks like

1. Most members of this highly distributed remote team will see each other again in 7 months from now.
2. Most of the new members (if not all) of the team will not interact with the community for the next year, maybe even 2-3 years, if the number of SREs attending such events remains so low/zero.

I understand that there are reasons, but they don't change the result.

Modern release management: complex web applications these days usually try control the stack they run on, via some manner of containerization. MediaWiki in contrast tries to support a huge range of potential systems and services, and mostly fails (in theory we support five DB engines but few extensions actually work on more than two; key features like WYSIWYG editing are impossible to install on the overwhelming majority of MediaWiki installations), the software not being able to assume anything about the system degrades the default the user experience (out-of-the box search is poor, out-of-the-box logging is poor, documentation is a confusing mess of trying to explain how to perform the tasks on dozens of different systems), and we are barred from various potentially valuable technology choices like isomorphic rendering.

At the previous TechConf there was consensus from a fairly wide group of stakeholders that distributing MediaWiki as a set of containers would still serve everyone's use cases as long as the WMF would provide enough support to make the process of installing, maintaining and upgrading containers user-friendly. (The WMF has not shown much interest so far though, and so there hasn't been any RfC or wider consultation beyond the TechCom participants.) This year's conference would be a good chance to establish whether there is an organizational will to do so, and how the concrete steps would look.

Gadget support: developers of on-wiki code (templates, modules and gadgets) get little support. We have a team for supporting external tool developers, and at least one for supporting developers of production code, and third-party code of a similar fashion, but the gadget development environment is still Stone Age, with no testing, CI, code review, barely any logging. There isn't even a central platform to store the code so all wikis have to reinvent the wheels. There were several attempts to improve things but they all stalled due to lack of proper resourcing. In the meanwhile, the importance of this kind of development is hard to overstate - templates/modules are a core component of all nontrivial wiki workflows, and of the reader UI, and gadgets are probably the most used among the volunteer-maintained tools. It would be nice to see some improvements there.

In T220212#5263887, @jijiki wrote:

@Rfarrand I am having some more concerns than just the possibility of being unable to attend a certain event.
While we are a 26+ people team (~1/4 of Technology if I am not mistaken), for 2019:

• 0 SREs at the Hackathon '19 in Prague
• 2 SREs at Wikimania '19
• Based on last year, there will be probably 2 SREs at Techconf '19

In other words, it looks like

1. Most members of this highly distributed remote team will see each other again in 7 months from now.
2. Most of the new members (if not all) of the team will not interact with the community for the next year, maybe even 2-3 years, if the number of SREs attending such events remains so low/zero.

I understand that there are reasons, but they don't change the result.

I super super sympathize and empathize with this. I just had my first ever team offsite at WMF with a team where every single topic we discussed was super relevant to me and my job. It was amazing and productive and within four days we were able to accomplish more than we could in 6 months of meetings on specific topics. I am a strong supporter of teams meeting in person and personally would prefer it to happen quarterly. However this topic is out of scope for this specific discussion and I don't think anyone following this task has any say or ability to impact how often your team can hold off-sites and meet with each other all at once.

As I kind of said above -the way that this event currently works is that the program committee is formed (by representatives chosen by Toby, Erika, Franziska) after the event is give a budget and participant cap and then the program committee works within those constraints. We were able to get a 20 person participant increase from the last iteration of this event which is some progress if the goal is to grow the event in size. But even if the event doubled in size and budget (not likely I guess with all the budget constraints) it would still not be able to accomodate every single person on every team at WMF who wanted to attend. Also keep in mind that this is a community event where we invite at least 20% volunteers so anything only relevant to a WMF team is also out of scope.

If your team has specific needs around meeting in person that are not being met that is not something that this event's program committee has the ability to solve. That would be a topic for your manager, director, c-level and so on. But really, again, I totally get it and feel the same way as you do around wanting more face time with my own team too!

To offer something, maybe SRE can propose a community friendly focus area for the 2020 Hackathon. I would be very happy to support that effort, help find resources, and help figure out a good plan. @Joe and I were attempting to work on that for the Stockholm hackathon but we ran out of time. If you can find someone from the team who wants to work on developing that we can probably pull it off together - but I guess we should discuss that on another task or by email so we can keep this discussion focused. :)

In T220212#5264131, @Rfarrand wrote:

To offer something, maybe SRE can propose a community friendly focus area for the 2020 Hackathon. I would be very happy to support that effort, help find resources, and help figure out a good plan. @Joe and I were attempting to work on that for the Stockholm hackathon but we ran out of time. If you can find someone from the team who wants to work on developing that we can probably pull it off together - but I guess we should discuss that on another task or by email so we can keep this discussion focused. :)

That sounds actually great! Thank you very much for taking the time to explain this, and to offer to help:)

One more topic suggestion: dealing with unowned code. We have huge and complex extensions (e.g. CentralAuth, OAuth, FlaggedRevs) and areas of core (e.g. file management) not owned by anyone. Most of these, we absolutely need (so it's not a matter of shutting things down). A lot of the maintenance of these code areas happens outside the books (ie. people finding time to take away from their jobs, or working extra time). Finding someone to make needed changes in an urgent situation (such as a train blocker / UBN) does not seem to be going smoothly either.

Reading through these, topics of interest to me:

• testing infrastructure and tooling, in particular further clarifying what work remains to be done in the unit/integration testing split up work that's been happening, but also, how can we improve the ability to run tests locally so we don't have to wait around ~20 minutes to see that a test only run in CI (phan taint for example) doesn't pass. Additionally, generating code coverage reports locally is too cumbersome (although getting better) and it would be interesting to discuss generating our code coverage reports from unit tests only (not integration tests) and how to encourage writing unit testable code
  • Also on testing, discussion on Selenium tests (T225248) and beta cluster (T215217) could be nice
• code quality and code health, more specifically assessing the usefulness of the integration with sonarqube for developer productivity, and if this is something that should be expanded upon, if so, how
• local development environment, in my first year at WMF I've gone from MediaWiki-Vagrant, to MediaWiki-Docker-Dev, to macOS homebrew stack (PHP, MySQL, Apache or sometimes PHP built-in webserver), to local-charts and then back to my homebrew stack. All of these projects have elements of things I need and all of them lack important qualities. It would be really nice to have The One True Way to Run MediaWiki and ideally this also replicates as closely as possible what we are using in production. Realistically that probably means local-charts is the future, but if so, how do we approach broader adoption and get more traction in addressing developer experience and performance issues with it?
• documentation as a newcomer to MediaWiki, I've cobbled together answers on "how's the best way to do X" from a) reviewing code from colleagues, b) reading inline method/class documentation, c) mediawiki.org documentation, d) docs/ directory in MediaWiki repo. Obviously a completely different domain, but in previous years I've used and admired the API documentation for Stripe and wonder if a repository that contains JS and PHP examples of how to do various things with MediaWiki (based on topics, like "How do I define a preference and use it server-side and client-side") would be a useful reference.