C. Scott Ananian wrote:
>On Thu, Sep 8, 2016 at 1:57 PM, Rob Lanphier <ro...@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
_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
