Page MenuHomePhabricator

Talk "How Wikimedia development works"
Closed, DuplicatePublic


At WikiKonference 2017 I had a conversation about interest in a talk "How does WM development work".
Probably similar to BMueller's Tech on Tour talks at German local meetings.
Wondering if we already have some materials to (re)use, filing this task to not forget to investigate at some point.

Event Timeline

Isn't this what @srishakatux 's intro is supposed to cover?

I see a difference in audience: IMHO Srishti's intro targets new potential volunteer developers. I was thinking of Wikimedia authors/readers/content contributors who wonder what those software folks are doing, and how it's planned and prioritized what developers work on and when.
Correct me if I'm wrong :)

Ah, that makes total sense. In that case you might want to partner with a community liaison? I believe they have a good idea about the statistically frequent things that editors get, get not, or get wrong.

The difficulties involved in future development and maintenance when every wiki wants to do some sort of specific technical solution.

Specific for the WMF portion of the developers: How we work in teams and what that means for who's supposed to do what (covered here).

How restricted we are by choices made years ago – making the small change they ask for could require doing enormous amount work because the possibility of someone wanting that wasn't taken into account in 2010.

How limited our development capabilities are compared to other sites of comparable importance and readership ("but I saw that Google ...").

That not all MediaWiki developers are employed by the WMF.

For me it would be, how almost unrecognisable (some would say unusable!) the basic software would be without /any/ gadgets, scripts etc. Even when a newbie signs up, they already get lots of stuff added by default, depending on the wiki.
And then most people are unable to even tell the difference between something that's core, and something that's volunteer-maintained, assume that their bug reports on random pages will just magically be read by the right eyes, and then get mad that nothing gets fixed when they'd want it to :)

I know it's a little generic, but should we maybe go over how software can quickly become complex with Just One Small Tweak? If I understand the audience it it not specifically technically-mined people?

We have a lot of tech-savvy (I understand how to put together a computer, run/edit a script), but not severely technical (programmers, engineers) editors. We also have a lot of folks who just use the software and don't (nor do they need to) care about how it all works. We shouldn't assume the audience has any knowledge and build from there.

Some semi-related notes at (feel free to retitle that page!)

A useful "see also" link for anything like this:

Re: the next level deeper, I was trying to do something vaguely related at - specifically, trying to get a simplified overview of a few levels beyond the table in - ideally with clickable imagemaps or expandable sections.

It might be good to describe the planning process. If you really want something big done, it's worth talking to the product manager (which means figuring out who that is) early in the calendar year, so that it can be put into the annual plan in April.

removing myself as I won't work on this soon and as I don't want to lick the cookie