On Thu, Sep 8, 2016 at 1:57 PM, Rob Lanphier robla@wikimedia.org wrote:
Good point. 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.
* how do we make manipulating the information on our websites easier and
more useful? (both for humans and computers)
Pro: a very broad topic, most reasonable subjects of discussion could fit under this umbrella. CF Cite, multilingual support, wikidata-in-commons, etc. Con: a very broad topic, would this even be a useful frame?
- 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. Con: not related to most of the other proto-topics I've heard floated. Maybe more of a "strategy" topic than a "dev" topic.
- 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. Con: again maybe more "strategy" than "dev"; doesn't help us discuss wikidata or refactoring the front-end. Also, why "software development community more inclusive" and not "editor community more inclusive"? The sharp division there might be a real issue.
- 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.
* 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?"
- how can we make our websites better support languages other than English
(and character sets other than Latin)?
Pro: I feel like this was deliberately aimed at me, and I like it. ;) It would serve as a concrete frame to recruit new participants from outside enwiki/SFO. Con: Do I have to argue against my own pander?
...
Ok, ok.
Con: the typical attendees of a SFO dev summit are not really the best folks to discuss non-English/non-Latin issues. It might be worthwhile doing as an "educate SFO developers about the issues" training summit, but if you actually wanted to set goals/make progress you should really host this topic at a non-North-American Wikimania.
=========
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?
--scott