Page MenuHomePhabricator

Theme: Local Development and Onboarding
Closed, ResolvedPublic

Assigned To
Authored By
Sep 27 2019, 6:26 PM
"Love" token, awarded by AnneT."Love" token, awarded by Tgr."Meh!" token, awarded by zeljkofilipin."Love" token, awarded by Addshore."Love" token, awarded by MusikAnimal."Love" token, awarded by Jpita."Love" token, awarded by kostajh."Love" token, awarded by Aklapper.


Theme program committee

@josephine_lJosephine LimCommons App Project Lead (Community)
@kaldariRyan KaldariWMF Director of Engineering, Contributors

Theme Proposal

Local Development and onboarding: This track focuses on:

  1. Our local development environment - specifically options, stability, ease of setup, and adoption
  2. Reducing barriers to entry for new developers via more efficient onboarding, clear up-to-date documentation, and inclusive support channels.

Session proposals

See sub-tasks


Wikimedia Technical Conference
Atlanta, GA USA
November 12 - 15, 2019

Session Name / Topic
Local Developer Environment and Documentation
Session Leader: Josephine; Scribe: Nick 

* 1) local development environment for mw core.
* Summary: most people think there should be a single and official core dev env, tailored to beginner devs and basic patch handling.  People really wanted to talk about complicated dev envs, but no consensus on what to maintain. Post event: Definition and code should live in the core repo, should evaluate existing ones to determine pros/cons. And decide whether or not to support SRE use-cases.

?: Existing dev envs were mentioned. Is there an inventory of existing envs?

DJ: Did we decide if there is a future for vagrant?
liw: absolutely maybe.

Mate: what are SRE use-cases?  JF:  swapping out components etc.

GT: take the role system wherever we go, if not vagrant

MS: Really want there to be an owner for that.

JF: problem definition stage always gets over-complicated.  If we want something slimline and easy to use, but also to have 4000 options, it'll always fail.

GT: Localcharts had similar issues. JF: Discussion will continue.

Florian: Who and when are we deciding which is the one? We know it should be one, and should be in the core repo, but which.
Jeena: There's already a ticket about that, but not sure if that was about docker or more generic. Perhaps should be more generic.

Florian: Should be a survey, and vote for favourite one.
AS: perhaps with additional questions.

AS: Should we put a deadline on it?
Tyler: Yes, but not before xmas.

AS: i guess the answer is something like docker-compose or localcharts, but i haven't had time to test either. I'm going to try putting a role system into my thing (mw docker dev).
Florian: I will take a look at that too.

DK:Want API testing for software updates.

KH: in addition to beginner, should have a standard thing that addresses 90% of use-cases for advanced devs too.

* 2) complex multi service development
* Session didn't go very well. Defined a set of personas for complex env. But there's not a one-size-fits-all solution. Instead focus on providing common tooling.

Does that mean making the env 
liw: there would be basically, based on which team, whatever they need can build for themselves. Otherwise making software for people not like you.
G: each team should have one person who decides on a setup for the team
AH: aim was to pick between different options, but cannot make a choice because each has a different use-case that matches diff needs.

JF: There would be some good core components, but too many edge-case people in the room to decide on any specifically. 

Florian: A lot of use-cases that are all completely different.
AS: even I as a single developer end up with multiple envs for different use-cases. A common base is a good idea.
Tyler: "production-like is not well understood" is my big takeaway. Different uses-cases have different definitions of it, and needs from it.

Riccardo: no consensus if there should be a few levels of complexity, versus standard core with modular components.

DA: I sometimes run into the problem of virtual box not in agreement with vagrant, is painful, lose hours.

DK: Has anyone used mw-docker-dev, works great for 
KH: not easy to extend and add-on. 

TT: need a few stacks that have clear strengths and weaknesses, and ideally not as independent as they are today.

KH: integration to testing environment, so that you have some guarantees it'll work in CI. E.g. like PHPfpm
TT: Overlaps a lot with CI.  Jenkins and quibble, core + bundle. Also [?] gate
DK: is there a reason to not conflate the 2? standard dev env be the same as env used in CI?
TT: making them behave the same would be good. But need some level of pluggability. Could be baked into an immutable docker image.
DK: similar to adjusting the CI env to a specific repo. Changes are of the same category.
TT: depends on solution, e.g. recompiling quibble to switch other Jenkins job, now it's just there. 

* 3) Documentation
* Should accept the reality that there'll be both onwiki docs and offwiki docs. But should work to improve discoverability,  and improve maintenance workflows, and improve the setup for offwiki doc translations. Recommendations have been sent to the WMF technical writers, and awaiting their feedback.

Pablo: people want the info in the repos to also be available in wikipages, so that you don't have to choose between them and can see it all in one place.
Toby: was this a developer view?
Pablo: using browser rather than opening the IDE to search twice (after already searching in wikitext).

Mate: session felt a bit limiting for me, in that it assumed [?mw docs?] are a good fit for everyone.
GT: That's been discussed many times in the past.

AS: I think there needs to be ONE place to go, and all the other places need to point to it.

Jeena: Would be great if there was  version control system, specifically linked to code-changes. 
Florian: have MediaWiki version x.xx docs with the code
LZ: Everyone always forgets to update the wikis.

Florian: how do we handle documentation of hooks, and perhaps find a better solution. Something better than the giant file for hooks.txt. [?]

BD: e.g. make requirements in checklists for updating docs (in any/all locations) at the same time as code. 
DK: generally we have code-level docs, classes and methods. Then usage level, how to install, etc.  As a new dev, there's no docs about how MW works. When i document it nobody maintains it and it goes stale, and unclear whether to put it in code or onwiki. Difficult to know if anyone will see it.
DA: That's a anti-pattern. My team has it triggered on deploy. Even if just doing a simple fix, do it every time, and build the habit.
BD+DK+KH: Hopefully Alex's work, on API and Dev Hub can eventually lead to this.
E: greenfield stuff, incremental updates instead of asking if there's one, just ask which to remove.

SN: Comparison to github. Maybe we could do a better job of surfacing our sourcecode in our docs. "Fork me", "Go fork yourself!" etc. I wish we had this more prevalent in our many toolings.

Piotr: Lots of our docs, the first line i can read, is "this needs improvements". I want a solid version. 
NW: related to earlier to discussions about ways to visually indicate the quality/reliability level of a page. +1 that it would be  good to have a solid reliable core of basic docs

SN: I found the specialAPI sandbox page really helpful. I wish we did more of that kind of thing. Live playgrounds. 

* x) Overall, anything missing or wanted?
G: I'd like a decision about vagrant. Continue it or retire it.
BS: for my SRE use-case, vagrant is essential
AH: ton of people require vagrant, but nobody is willing to maintain it
DJ: In my experience, anything built for something that doesn't run in production, nobody is going to maintain it. e.g. puppet modules.  This is the most essential problem vagrant has. 
DJ: +1 to making a decision, either do something with it, and maybe make it required, or make it something new.
Pablo: can we iterate the list of typical dev envs, poll to ask people to vote on which is their favourite. docker vagrant homebrew etc. Need to understand current reality before we look to the future.
* Define where we are
* Decide where we want to go

Stephen: Not always clear the best platform to communicate updates. Phame, Spaces, etc etc.

Petr: been a long time since our own onboarding, We want clearer feedback from the newcomers, regularly.  
SW: Should give our own feedback more proactively when we're learning a new area. Especially when we get the benefit of mentors.

SN: Outreach to new devs, onboarding -- what can we change to invite people. Did we already have that conversation?
JL: Not a focus at this conference iteration.

Z: mixed feelings. I need an answer on this daily. Feel lost putting effort into this. Sometimes i write docs, and half the time is on "if you're in this env, do x, if you're in this other env, do y".  Docs would be a lot clearer if we had fewer. But primarily I want there to be a decision that we absolutely officially support any/many of them and specifically which ones, because currently there's nothing official.

Event Timeline

josephine_l renamed this task from Theme: Local Development and onboarding to Theme: Local Development and Onboarding.Oct 2 2019, 10:28 AM
Rfarrand updated the task description. (Show Details)
Rfarrand updated the task description. (Show Details)

The session proposals will be added to this task tomorrow and an email will go out to techconf attendees asking for feedback on theme and session proposals before they are finalized.

I made this point in T234632#5571246 in more detail but IMO separating the topic of local development from containerization in general goes against modern trends somewhat. When you do it right, those two things should be the same.