Wikimedia Developer Summit/2018/Growing the MediaWiki Technical Community

Growing the MediaWiki Technical Community

https://phabricator.wikimedia.org/T183318
Presentation: c:File:Growing_the_MediaWiki_Technical_Community_Dev_Summit_2018_session_slides.pdf
See task for session description, goals, and pre-reading notes

DevSummit event edit

Day & Time: Tuesday, 9:40 am – 12:50 pm
Room: Kinzie
Facilitator: Nick
Notetaker(s): Brion, Niharika, Legoktm, Santhosh, you?

Session Notes:

[intro section]

Slide difficulties (follow along above!)
Some overlap with other topics (embracing open source, etc)
Start with overview of problem areas, then go into focus groups.
Session is 'Growing the MediaWiki technical community' - what does that mean? We'll talk about the MediaWiki tech community, and also the Wikimedia community, and we will talk about an ecosystem of open source communities. Note that labels mean different things sometimes to different people.
One of the questions was how this connects to movement strategy...
Explain why it's important to grow the tech community:
Want institutations and people to participate; be a partner in free and open knowledge... We see the free/open-source MediaWiki platform as part of that knowledge sharing. Emphasize that this is part of Wikimedia's core mission -- not just sharing information, but enabling people to participate in doing that. To improve our software and create more diversity of viewpoints in how it's created. Can't do all this alone -- need to take advantage of other orgs with shared values and shared mission.
Increasing the diversity of the technical community -> more people contributing, and more perspectives with different ideas and viewpoints. Ensures that people with diverse backgrounds etc are contributing and taken into account.
Some typical problems.... Having grown into a fragile complicated system with technical debt! How do we improve -> reducing technical debt can help reduce barriers to entry. Really hard for people to join when hiring new software developers, have to introduce them to how everything works ... it's a bad sign how much needs to be learned. Documentation issues: if we don't document well it's hard to work. Working in silos -> teams not talking to each other. Some projects need multiple people... need to talk to each other. Working in silos a lot.... How to make people part of the network? Last example: 'home is where my gadget is', lack of standards, difficulties in maintenance (?),
Want to take knowledge .... yes we're doing better.... We have infrastructure for open source, strong mentorship programs (gsoc, outreach, gci). some documentation and outreach is redundant or confusing. Our community is probably one of the best in terms of (?)
-> slides fixed! <3
[continuing at slide 9]
Our is one of the better communities in terms of wants to start contributing -- templates onwiki, lua onwiki, gadgets/userscripts, server stuff with python, puppet, MANY ways to get into the technical community. We run events - hackathons etc, try to keep up and work together with folks. Tagging - 'easy tag' on phab tasks etc to help direct people. Tech advice IRC meeting... MWStake communicating with outside users...
Best practices from the wider open source world we could consider adopting:
"training missions"
structured practices for managing project cross-org (cf Apache)
consistent and accurate task recommendations. 'easy' tasks a start -- could be curated better, sometimes tagged inaccurately, want better ways to handle recommendations
better code review practices. especially for non-WMF/WMDE folks it can be tricky to get code reviewed.
large scale software collaborations -- cf webkit -- things that are too large for any one org
Brings us to what we want to focus on today: How can we include all developers? Will spend first hour on this before break. Afterwards, continue with 'build up open source partnerships' -- re partnerships we don't have yet, what would they look like and what should we do? second half of session: technical debt, how does that affect community processes.
Want to hear all the voices in the room... what would help you develop more efficiently? For those who don't but plan or communicate about it, how does it affect you? -> discuss what we should do next... and put it on the etherpad :D
Designers, etc, others all are welcome.

(Comments, starting back to front)
[repeat the question]: what would allow you to develop software more efficiently, more fun... 3 hashtags.
[Victora] dunno about more efficiently, but [?] - don't have a good way to align the values we have in the codebase with the org -- gaps. tell people - if you work in this area, you'll be able to see it get used ...
[?] better documentation and entry points, all the things that are very complex
[Victora] (?) need better coordination with outside...
[joel] Super-specific test -- if i were to dev something in my own time i'd want an ubuntu installer, an in-person party where someone can help me install, and a list of bugs that i could fix
[katie] Need to be really careful as foundation people to prioritize on efficiency. volunteers have different time availablity, may come and go... their efficiency may not match our schedule. Full-time employees don't want to optimize for their own efficiency in this case, because mentoring is never the most efficient solution for immediate problems -> optimize for not wasting the volunteers' time? not sure how to hashtag this
[moriel] think that clarity and transparency is something we really need to work on in all stages of our product pipeline. what do we give the community as the foundation? resources that volunteers don't have... research, flying people out to events, hardcore research... we can help volunteers in their work with these things. need to bring someone in at any stage... we're not as good about encouraging volunteers to help us out with *products* we work on. and +1000 to joel -> installing our environment is a nightmare. vagrant makes it easier but not perfect. we're ignoring windows: it exists and people use it! i said that at a linux conference and almsot got booted off stage ;) not a lot of people understand it and know how to deal with it. can't just tell volunteers to install a vm to work in ubuntu. installation is the first step before can contribute. can take hours, very frustrating, people often drop out on this step alone.
[lucie] following up -> don't force a huge software project on someone. need to be able to read a bit of docs and then work on something small. right now need to know who to ask about things and chase down lots of details -> time consuming, not fun, prevents getting done. just don't have the time.
[leszek from wmde] one thing that comes to mind: our whole infrastructure/framework around dev work is quite ... "special". we don't use github for example while many others do. we have our reasons, but take into account that it's extra impediment which can drive some people off. phabricator. installation issues. Doing some work with showing people where they can contribute with easy tasks, but need to do better -> direct people to what they can do that will be appreciated, and won't require a 6-month project at wmf to follow up!
[giuseppe] response: github is a huge problem for open source in general, centralized single company. but we might want to use something more common than gerrit -- ex gitlab is more familiar. we always have the option of installing such things ourselves. github itself is an issue for the free/open source community generally, am annoyed that some parts of wmf are using it... think about using gitlab or something else we can self-host. (https://phabricator.wikimedia.org/T167547 Use gitlab -> Declined)
[markus] mostly outstreaming to github, but what about in-streaming the *users* who are on github? have heard several people say they would contribute more if they could use their github account. secondary: code review & external resources? many extensions never get +2s on their patches due to the extension owners being the only one with rights, etc. currently the burden of failure is put on the volunteers... need to know that someone's going to work with you on something, and it's more fun to work on something that has a chance of getting implemented.
[moritz] a few points: one misconception in my experience as a volunteer is that all the tools make it nice to get on board... spent a lot of time with vagrant which was frustrating: realized nobody else was using it within foundation or at least few people. "eat your own dogfood" -> make development nice for you so it'll also be nice for volunteers. not a problem to use gerrit, but need to write down how to install it, use it so others can do so. don't have a _separate_ process for volunteers, but make a _better_ process for all that works for both wm devs and volunteers. A microproblem that blocks people on a daily basis -- where you are, where you can go, and when you will get to the next stage... worked with a few students over last years, had frustration that they didn't know where they stood. sometimes something moves very fast, then nothing happens for months. have a process to have dates -> make the decision process more transparent. let people know their state and timeframes.
[nick] So, challenge around system setup, and action item to improve the vagrant etc. and Challenge around expectations responsiveness
[matt] use of vagrant is split -- some use it some don't. if you don't like it, maybe contribute to another system like docker....
[giuseppe] our other software is worse than mediawiki at taking contributions... free software but "open source" needs more. need to think about making our software a little bit more useful for others, not just for ourselves. my personal experience: started contributing to free software because there was some feature in the software i wanted that was lacking. if something's not usable by outsides, has a steep learning curve, we'll never get contributions from ourside. mediawiki's established enough but the ecosystem around it harder. not sure we have been thinking from the start that our tools should be usable for general purpose. citation for example -- specific to wikipedia but could be used elsewhere, but we don't think about framing it that way.
[joel] direct response to moritz: students wanted more feedback on when stuff happens?
[moriel] please join us in the next session about building open source -- libraries, us contributing back to the world
[benoit] sometimes work with outside users... but not able to tell them where to start, it's very confusing. even confusing for me! difficult to find the first step for someone to get on board as a developer. just to ask a question -> where to do so? many places, don't know where to direct them. People want to know where they can go next... need to know someone will review their work... For people from the outside it's very confusing to find where to start.
[legoktm] something different -- giving more +2 rights? we gave _no_ volunteers +2 rights in 2017. 2 in 2016, 4 in 2014.... this is worrying. expecting the wmf/wmde to review all code is unreasonable and is setting us up for failure. (core and extensions.) need to figure out a better process for giving people +2, this isn't working. yes we want quality tech, but we do have enough trusted volunteers, people generally know which code is safe to merge.
[lucie] do we have any extensions maintained primarily by volunteers? can we learn from those in some way?
[cindy] direct response: (with my volunteer extension developer hat!) as a longtime volunteer extension developer, want to echo a few things i've heard. first it's very important for extension developers to use the same source control that the foundation/most mediawiki code uses. really important that extensions get put into gerrit. there *is* definite pain in that that would like to see go away.... always tried to create repo in gerrit etc, but doing that through a work VPN network can be a pain point too. Past that -> code review, +2 rights: if an extension is developed by a volunteer as prime maintainer... and there's great extensions out there, some applicable to WMF projects, others not but still great for growing the community -- would like to see those get the same love. Where extensions have a single maintainer; might still be widely used in 3rd-party community, but those people don't tend to participate in gerrit even if active in phabricator for tasks. Few outside folks will comment on changes in gerrit. Have often had to +2 my own changes in gerrit on extensions, which is frowned upon. Need better rules for people who are sole maintainer of an extension. Documentation, patches, etc... [Need better documentation that +2 is ok on self-owned extensions!] Would like a better system for folks who want to play well in the system to get *code review* to get expert feedback. Just this week got feedback from an old ext that added columns on 'user' table (know now to use a separate table!) but would have been *great* to get that feedback 5 years ago! Have to migrate users now. :)
[kaldari] re community tech's github experiences. community tech does a lot of projects directly with community members often working on tools that have already been created by users on github... also do projects on gerrit. I've found that we get more user interaction on github -- it's easier for users, system's more integrated, etc. Very aware why it's problematic (commercial, walled garden etc). But we kind of live in a github world, and to some degree we should interact with it. Just saying we should never use github is not enough. When things already exist, just keep using it? Sometimes we've started very small projects on github - small, general use libraries. Chose to do that to make it easily discoverable and easy for others outside WM world to contribute to. But for anything else mediawiki-realted we use gerrit. Just want to open up some discussion there.
[mark h] a whole separate thing for how to interact with github would be good. it would be possible to accept pull reqs from github and merge them into gerrit... A whole thing of some sort would be helpful.
[giuseppe] I know some places where this is done; hhvm for example. underwhelming experience, could be better but takes resources -> is that what we want to spend money on?
[bawolff] one of the things with github is not the walled garden, but just that people are not using the official thing. like having bugzilla plus other separate bug trackers before phab days.
[tgr] toolforge environment is a lot easier to learn: no (required) code review, much less depednency on WMF-developed poorly documented code, hosted environemnt where you just write the code and it runs without having to set up any environment, no need to use gerrit
[jamesmontolvo] a lot of things discussed here in last two days have been discussed before year over year -- re working more efficiently, having more fun -> let's get some actions. Would be great for morale for next year as well as getting things done!
[Leszek] <context: https://lists.wikimedia.org/pipermail/wikitech-l/2018-January/089381.html> folks at WMDE excited about the idea of recognizing code reviewers and making it a bit of gamification [?] +10
[legoktm] review stats tool is a fun motivational tool! http://koti.kapsi.fi/~federico/crstats/core.txt

Spent some time collecting things that might be fun for you -- but collected more problems of things that need work? Asked for "fun" because in the end we have to implement what we change. We need to want this! We want fun things more, so. :)
For last 21 minutes of first part before break: look at what we've collected and come up with a prioritized list. Some big broad topics and some very small topics. Can we create action items, identify low hanging fruit?

[katie] Action item suggestion: Revise WMF +2 right policy; look for new ways we can safely trust people more readily.
[?] general procedure note -- somebody should present at next year's summit what got done/not done! And everybody should fix at least one bug that affects them in their daily life as a foundation/etc developer. Make a ticket now and see how many are closed next year.
Will create followup tasks... some will of course have to resourced later!
^ assign someone to present for next year, not for the bugs yet!
Doesn't have ot be something you do on your own, can shepherd it with other people... volunteeeeer!
Going back to ... let's gamify like the "review one patch a day"!
[moriel] Get interns to do tutorials... mentor how to get newbies online.
[lucie] Shouldn't expect volunteers to do the dirty work we don't want to do. As a volunteer saw Foundation as being paid to do the boring stuff noone wants to do!
[moriel] there *are* people interested in doing technical writing, though. :) problem we're encountering is that the amount of existing stuff is so huge, need to review/fix stuff. for gci etc: need tutorials that aren't _for_ us they're for the newbies, and those don't often get done by existing dev work.
[joe] my first 10 patches to free software were just documentation updates. it's a good way to get started
[matt] gci is good for getting folks to work on small tasks too
[santosh] Feedback from google code-in summer of code after they finish their project. is helpful outdated docs an issue, things not working as expected. this slows down contributors doing other work. identify actionable follow-ups from these issues, including doc and other work. Expand it further for other contributors and do a follow up to ask what kind of difficulties they had.
[matt] re recurrent issues/questions -> the technical advice meetings helping to surface some of these now. agree needs followup
[tgr]
- Have a documentation day, where devs stop developing during one day to focus on docs has been done once and has been pretty successful. Do it again, regularly?
- Some problems with documentations are too large to fix on a volunteer ad-hoc basis, we need to start/propose a project for fixing them. One such thing: really hard to use documentation for things that change from release to release (e.g.which hooks is an extension using); we would need a structured data store so we can extract per-release data from git, put it in the store, and access that from templates.
[Birgit] recommendations for projects to work on: people tend to prefer tickets on existing projects more than new projects. How to recommend new projects? How to motivate people to join new projects?
[Nick] Triage #easy tasks to be sure the task is really easy and understandable? And if not, remove the #easy tag? [side comment, Andre does that]
[matt] similar; other issue: add programming languages etc on those easy tag tasks so can query something that's relevant to what someone knows
[leszek] are easy tasks easy but boring? -> outsourcing to volunteers...
[matt] to do a trivial change with say i18n may have to get a lot of stuff up and running. it's not trivial
[benoit] differences between available time, goals, interests... Don't create a gap.
[birgit] common issues: fix installation, fix code review process (+2), fix docs, refactor recommendations ('easy bugs'
[SJ - how can we help people who want an easier {install + despam + maintan} toolchain contribute to that toolchain? Fixing installation & real-world use should multiply new devs beyond those who want to solve those problems.]

[BREAK]

PART 2.

What other Open Source communities do we share interests with?
- What would be good new projects to start as a brand new partnership? With who?
What are the main challenges?
Ideas for next/first steps (action items)

[Matt] some tasks big/important to movement but not "ours". Usually in software we think in terms of "ours" or "upstream". Cite, Multimediaviewer etc are "ours", hhvm is "upstream". Explore a different model that's more of an even partnership with other organizations... Put in annual plan a commitment to something with another org? Big examples: machine translation, audio/video codecs, etc. If we want to push them have to work with other orgs who develop or use them. Some questions to prompt...

What other open source communities do we share interest with?

[mark h] the php community, the nodejs community.... can keep mentioning languages :) would love to see cooperation with ... have encouraged it but haven't seen much yet ... witih composer for instance, though it seems like a closed environment of their own.
[legoktm] wrt composer, we've had both good and not so good interactions with them upstream. but they know us (me, reedy and bryan davis at least)... happy to implement patches etc usually now. For upstream projects like Firefox and Mozilla, could improve! though we have good rels with Chrome team. Debian -- lot of us are debian contributors and devs. One of the biggest ways to make sure something is available on wikimedia is getting it into debian; once you can apt-get install something the chances of being able to use it in production goes up dramatically.
[Madhu] Cloud services is also an area where we collaborate with open source projects - JupyterHub, Kubernetes etc. Also, all the projects we work with, phab etc, are all open source projects, that we don't _actively_ contrib to, but ... should set something up
[moriel] two quick points: should think about what partnership means. there are things we work on upstream; but wikimedia deals with different issues others do sometimes (scaling or lang etc). is a partnership something like pushing jquery.i18n? should we open it up a bit .... if we were doing a partnership with another community (example: composer); eg officially recommending people work on it -- is that community something we want to support? might have a toxic community even if it's technically nice -- in which case let's not send our volunteers that way maybe.
[birgit] This aligns with the movement strategy: We want to work with people, projects, institutions we share values with.
[kaldari] I got the email address of the bugmeister (Liz Henry) at Mozilla and she's really helpful, but otherwise working with Mozilla can be difficult. (ICU project for internationalization is something we use a lot, would love to support them more directly!
[katie] success story from fundraising tech -- for as long as i've been around, all the donor retation data has been stored in civicrm (major open-source tool). we are their biggest installation! we used to have lots of problems getting them to reproduce bugs but we really needed them fixed. ended up hiring one of their core developers -- they work with our team all the time now. If they can't repro, they *want to* no so nobody else hits the scaling issues that we do! If there are opportunities to take this approach, go for it.
- a lot of chapters also use CiviCRM.
[giuseppe] katie spoiled my comment. ;) we have some formal resistance to the idea of formally funding the work of other orgs. if we want something from another community, the most logical way is to help fund it. even outside developers.
[mark h] (direct response) i agree - that's the way open source is supposed to work. but there's a resistence even among wikimedia about going the other direction... have a number of clients who would love to hire devs or wikimedia to *do* stuff but there's no good way to do it.
[tgr]
- regarding libraries, we have a strong Not Invented Here syndrome - there are common functionalities every large PHP project needs (HTTP requests, dependency injection, shell execution etc) and there are high quality libraries out there (e.g. Symfony) but we just roll our own
- Want to echo Moriel, we should look at downstreams instead of just upstream. We maintain the only PHP HTML5 compliant parser / CSS3 parser / IE 5-6 security libraries, all cool stuff. But only MediaWiki users knew about it. We made no effort to publicize it. It would give us a lot of input and new efforts on this. New developers are having hard tome to step-in.
- we also do not interact with standards bodies that are highly relevant for us (e.g. PHP-FIG, W3C)
- we don't strategically invest into opensource projects working on something that would solve a long-term pain point for us (e.g. Matrix to solve IRC usability issues) even though we are very well placed to use our brand or fundraising connections to help projects in cheaper ways than paying someone to directly work on them
[matt] focus beyond existing upstreams and projects, what are good new projects to start as partnerships
[legoktm] embedding mediawiki into say nextcloud? or wiki publishing mode in LibreOffice...
[benoit] get helped by initiatives like Google Code-in or Outreachy to find new developers. work with other orgs doing content editing -- openstreetmap for instance for technical expertise. affiliates & chapters we're used to working with too, but onlt tech issues that affect them not as resources to find new volunteer developers.
[matt] moving on: what are the main challenges of this approach?
[santhosh] ... time & resource needs?
[matt] that's part of why we need a new way of thinking about partnerships, can't be something people do in their free time aside their real work. needs to be something that wikimedia commits to as part of their work.
[niharika] need rtl support in CodeMirror, either figure out how to do it ourselves or pay them to do it! resourcing question is still open
[katie] funding is a big thorny issue for us. was 'easy' for fund tech to justify hiring someone because we work in dollars all the time. it's a lot harder for other teams to balance the donor money against needs... funding trade-offs and looked first at short-term contracts before hiring someone (versus shoveling tons of money at salesforce or something) -- had to confirm with the contractors we want things solved the *right way* and upstreamed, not just a quick hack.
[birgit] ... (summarizing) ... need to think about how we connect needs to movement strategy etc?
Examples with firefox, composer.... often single people have contacts at institutions but there's no structural connection. Who do you talk to to get it done? Hard challenge to connect things at a high level. One group has a contact, another has another, don't know about each other. Combine our contact lists!
[legoktm] https://www.mediawiki.org/wiki/Upstream_projects lists some of these, needs updating
[matt] [?]
[nick] what kind of problems might there be in terms of making sure people don't get unduly nagged about issues?
[legoktm] these are individuals who know somebody on the other end...
[matt] some concern about privacy on individual contacts...
[birgit] First: challenges, now some action items? But first, what do we think about what we've been discussing so far? Interesting to focus on or not?
[... lost a few ...]
[Birgit] any projects you think would be great to have a collaboration with? This session is good for having follow-ups -> next hackathon, wikimania etc. Anything we should focus on?
[Brion]: PHP - our entire stack depends on it, we should be more involved in its development. [forgot to say out loud that I want to contrast with what FB did in creating HHVM from scratch without submitting improvements to Zend PHP. want to actually involve with upstream!]
[Benoît] Any organization to review our documentation, our processes and audit our tools around involving new developers.
[santhosh] Apertium, machine translation engines... getting/giving feedback. expanding to more languages is necessary.
[Birgit] Any other point?
[matt] Add Maps (OSM).
[leszek] sounds ambitious but why not?
[matt] wanted to add it to part 1, but no time: reinvisioning the foundation project planning ... letting people be members of a 'team' without as much regard to which employer they're with.
[SJ: What about non-software communities w deep shared interests: translator, libraries, environmental, anarchist, openbio... sometimes identifiable b/c those communities use a wiki or other free-software collab tool as their primary online presence. their tech subcommunities are potential collaborators, and their nontech members can help identify/draw in more. ]
[santhosh] working more with standards bodies -- w3c, unicode, etc
- would PHP-FIG also be considered under this heading?
[katie] came to conclusion that defining processes in terms of product wasn't deliberately being exclusive, but often they end up being. reusing models like 'agile' and 'scrum' that are designed around predictably putting software in a box and shipping it... that's not what we're doing. set number of people with a standard velocity that you're paying to be there all the time isn't representative of everything we've got.
[Victor] +1 to santhosh -- another standard body to work with is schema.org. as an org, mission, movement... wikimedia itself has great impact, we should feel free to be more vocal about standard devising -> we have impact when we adopt a standard. We can take a lead in creating standards sometimes.
[matt] about intentions... we always want more volunteers, but don't invite them to the standups etc. need to take a more structured approach about how we integrate volunteers, not just say we want them. hope we can experiment with that... spin up a new team with an experimental cross-org structure for instance. the volunteer problem is hard in that time avail is hard to predict, but they can say how much time they have, and feedback loops.
[mark h] i'm very interested in being more involved in the pdf rendering/book creation. who can i talk to at this conference about that?
- CScott. See https://github.com/wikimedia/mediawiki-extensions-Collection-OfflineContentGenerator-latex_renderer and related projects.
[katie] i would love to get a small group together with some PMs -- any structure/methodology we accept doesn't *automatically* mean volunteers are out/in. it's just a different timescale. want to talk more about this....
[birgit] in terms of how do we reach our goals, what's the measurement? healthy teams coming from different backgrounds/perspectives might be good even if it takes longer to do something.
[matt] agree working with volunteers has a different timescale, can be difficult. if you have a specific feature and want a volunteer to do the frontend, that will probably take longer than a full-time internal employee... but maybe we do that while internally working on the backend, etc.
[madhu] discoverability of what projects exist... if wanted to get something into say GCI there's a high cost to making sure everything's ready for them to work with us. Need to make sure have those entry points for people consistently, so each individual manager doesn't have to reinvent.
[matt] agree, don't want to make every manager do this selves. maybe get some together, develop plans and a pilot program
[sj] space for technologists to contribute... often people know what they want to do but there's a mismatch with how we do something. maybe figure out a separate 'technical space' for people to just build Things. ("toolforge?") yes but a social space for people too -- how do we invite people form external groups to come in and work with each other as well. don't just pick up threads of old debates about why can't do something.
[matt] part of that is we can bring them here, but we can go there too.... sometimes contrib to upstream projects, but should go "out" more and interact with those outside world.
[birgit] last topic? ok ... when we were screening position statements, lots of notes about fragility/tech debt and that slows people down, frustrating when things break. How can we grow the technical community by *using* technical debt? Should have a process to address this...

How can we change our processes to take technical debt more seriously?

[Leszek]: general idea - do something about gadgets. My experience with gadgets is that it is difficult for people to work with gadgets, make changes in a way that they don't explode. A framework for people to build gadgets with perhaps?
[Brion]: Content projects. Spelling errors, formatting issues etc. People love to make projects around those things. We need to have something that makes it easier to track those issues (maybe not another bugtracker), maybe "Easy" tasks tag...
[Birgit]: Gamification idea again. People actually have fun doing that.
[Tgr]: Three different areas: "professional" codebases (gerrit etc), ToolForge, on-wiki. Fixing professional codebases is hard (plenty of resourcing already), Toolforge has it's on team now and seems to be in good hands these days, the low-hanging fruit is on-wiki stuff (gadgets, Lua, templates). Development environment is terrible (text editor, no review workflow, no easy way to test), connecting MW to Github to and do code review and CI there would be a big improvement. Talk to tgr if interested.
[Katie]: CiviCrm tags section of code as "toxic code". Rule to leave it better than they found it when they touch it. Bit informal. Nice approach. We can learn something from it. https://wiki.civicrm.org/confluence/display/CRM/Toxic+Code+Protocol
[nick] are there best practices from elsewhere we want to adopt?
[niharika] if teams could dedicate some 10% of time or something to tech debt, that would be great... that's a product question (resources) of course
[nick] we used to have a 20% time policy but everyone has 200% work so the 10% time falls off :(
[leszek] since beginning of this year at wmde, had rule that of your dev time, 30-40% on dev time, 40% of maintenance. that's not all tech debt, but it's part of it... we're only a couple weeks in but good so far.
[tgr] 10% time traditionally for side projects, maybe good to keep that separate from tech debt time. People get recognition for spending 10% time on side projects but not if they spend it on tech debt. Cultural problem.
[Bawolff] seems like people get very obsessed with tech debt, but not sure it's as big an issue for driving people away... [?]
[Giuseppe]: Agree with you, ???
[Birgit]: What leszek said, 40% helps us in scaling the projects - not about delivering great new projects all the time. You can explain to users that this would help with having projects sustain longer than quick fixes. Totally worth explaining. Don't build a house in a day unless you want to have no roof!
[Victor]: Understand the argument for and against tech debt. My 2 cents - we should treat tech debt not as a vague undefined thing but spend time finding specific problems - set goals to achieve better problems, find the specific problems, have clear goals. Product is really vague when talking about shipping products, treat tech debt as a project.
[james m] Applies to documentation as well.
[Victor]: Speaking of documentation, there needs to be measurement - what works, what doesn't.
[Matt]: Measuring documentation is a good idea, we have a software for that. Disagree on tech debt being a..???..really depends on the features.
[Birgit]: Tech debt is an abstract term. Identifying different areas, making them into products and projects with proper planning.
[Leszek]: Agree problems with code are barriers to contribute. Seems like tech debt is a cool thing to say, demonized thing. What exactly is the problem its going to solve?
[Victor]: Categories of tech debt - design patterns, quick n dirty logic etc. Any infrastructure this system can leverage that it hasn't, any infra this system depends on, not enough comments.
[Mark H]: Problem is readable code - core functions going on for pages, comments aren't gonna help.
[Kaldari]: Even when we do have comments, the comments are unreadable - pseudocode like. Developers forget comments are for explaining, not for code.
[]: Developers have to find a natural need to write comments
[Nick]: Canonical examples of places where its done well.
[moriel]: make sure everyone on team knows you have to document -- make sure properly commented or -1 it.
[Victor]: How can you scale up your tech debt solution? Can you build workflow processes that enforces quality of comments? Start enforcing quality of comments in code review. Also build examples to cleanup code. Coming as a contributor based org, we need to be creative in finding ways to motivate devs who can work on tech debt solution. Make it exciting for them. For example, changing, swapping interfaces is heavy work - like Java 8 comes out - there were tools which can detect changes and swap in and create auto-commits on large scale. Linting tools to detect if code has certain format.
[legoktm] NS: we have some static analysis tools already, but we can do much better. Mostly need more people to contribute.
[Benoît] Worring about commenting in the code. From an external POV, that's don't look like the best way to discover where are the old problems. Document outside of the code is also needed, especially on both code and project history.
[Katie] NS: In my experience, it's not the engineers that need to be motivated. Generally, it's non-engineers who don't understand why you'd want to spend a sprint or two to have everything essentially work the same way from a features perspective. Engineers frequently have to sneak in refactors attached to other work.

[Birgit]: Some conclusions:

Allocate significant resource in teams to maintain this.
Categorize technical debt in different areas, define products/projects to adress the problems.
Emphasise code quality culture in teams
Having standards for gadgets so people have easier time knwoing what to do

[Benoît]: Not sure of those points. Have an external POV may be needed to see if we are wrong on what we decide based on our extensive knowledge of the project.

If there are related links, please list them here:

Growing tech community:
1. Key common issues: https://www.mediawiki.org/wiki/File:WMdev_2018_tech_community_common_concerns.jpg
2. Other captured issues: https://www.mediawiki.org/wiki/File:WMdev_2018_technical_community_pain_points.jpg

Action items, next steps, and owners:

reform how we do +2 rights (making it easier to get review done for small exts, etc)
1. <- owner?
fix documentation (better tutorials and entry points for newbies)
1. <- owner?
refactor our recommendation system (better tools than just "easy" tag on tasks)
1. <- owner: Birgit can kick it off and start talking to people (engineers, teams)
improving install process for devs (installer, vagrant, other?)
1. <- owner?
Make our continuous integration output easier to read/understand (linting and unit testing output)
1. owner: RelEng team
Combine contacts from WMF/WMDE etc
1. relevant folks should update https://www.mediawiki.org/wiki/Upstream_projects
Formal processes for inter-org communications to not be dependent on individual contacts
1. <- owner?