On Thu, Sep 8, 2016 at 1:57 PM, Rob Lanphier <[email protected]> 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
--
(http://cscott.net)
_______________________________________________
Wikitech-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
