C. Scott Ananian wrote:
On Thu, Sep 8, 2016 at 1:57 PM, Rob Lanphier robla@wikimedia.org wrote:
Let's say that we had to pick only one of these questions to answer at WikiDev17. Which would you choose?
All of them! But since no one else bit Rob's bait, let me try to give a pro/con for each.
I considered taking the bait. I read the questions, but my primary thought was "man, this guy seems way overdue to submit a Gerrit patch or do something less highfalutin."
- how can we better distribute the information on our websites?
Pro: invites radical thought disconnected from monetary/fundraising needs! How can we get everyone to use our stuff? We collectively probably haven't thought hard about this recently.
Plenty of people have given this thought. Offline reading, printed editions, putting Wikipedia on the Moon, Wikipedia Zero, etc. We can do more, of course, but that's true of everything.
- how can we help our software development community be more inclusive
and productive (and attract many more people)?
Pro: again, big thoughts, on a topic which deserves attention. Can drill down into nitty-gritty like, "why not github?" and "can we make the review process more friendly?" which are favorite topics for fat-chewing among developers.
Wikimedia-related Git repositories are on GitHub. If we want to attract more people, that requires figuring out how to scale up the already shaky code review process.
- how can we improve the quality of our software, and pay down the
technical debt we've accumulated over the years?
Pro: again, a favorite topic of talk-over-beers among developers. One could imagine a whole summit devoted to going through our software stack component by component, identifying the cruft hidden in each, and making concrete plans to banish it. Con: this opinion might be controversial, but my impression is that we're actually pretty good at low-level refactoring. There are plenty of things we are hesitant to change (say, wikitext syntax!), but I don't get the feeling that the barrier is in engineering. The problem is mostly a management one: how can engineering communicate the time spend and value added by "invisible" maintenance and refactoring; how can we get management to allocate more dedicates resources to this? I don't think there's much technical debate about what to work on, if we had the resources to do so.
I think this problem exists in most companies/organizations. Nobody wants to pay down technical debt; building new features is a lot more exciting.
- how can we make our websites better learning environments?
Pro: another radical idea, and I like radical ideas. ;) Con: We have wikiversity for this. Yes, it has its problems. But wouldn't this topic be better phrased as, "how can we better support wikiprojects other than wikipedia?"
Yes, that's better phrasing. But it's still too vague to be useful. As I read this question, I hear your comments about "strategy" v. "dev" echoing around in my head. How we can better support non-Wikipedia projects might mean setting them free/abandoning them.
Ok, so what have we learned from this? Even if others have different opinions about each of Rob's proposed topics, which are the *sort* of things we'd like the dev summit to be about? Radical ideas? Stuff developers bitch over beers about? Vague umbrella topics ("make wiki easier to use") that we can crowd a bunch of stuff under? Something else entirely?
In my experience, the greatest value derived from these types of events (summits, hackathons, unconferences, whatever other cutesy word) is having unstructured time to explore and think and poke and discuss with people about pet projects and other neat ideas. The structured and more formal sessions, with their broad themes for whatever year it is, are usually boring and ill-fitting.
MZMcBride