IRC office hours/2009-10-07

Philippe|Wiki: ********** LOGGING ***********

[11:02pm] eekim: hey philippe

[11:02pm] eekim: hey everybody

[11:04pm] eekim: we're deep into task force selection right now

[11:04pm] TimStarling: just asking because serita cox has been emailing me

[11:04pm] eekim: hi tim! missed your question

[11:04pm] Philippe|Wiki: TimStarling: Yeah, she's definitely on that team, but shes not here tonight

[11:05pm] Amgine: :[9:01pm] TimStarling: any bridgespan people here?

[11:05pm] Amgine: (for eekim)

[11:06pm] eekim: thanks Amgine

[11:06pm] eekim: nope, no bridgespan people tonight

[11:06pm] eekim: what sort of questions has serita been asking?

[11:06pm] TimStarling: she's left me a bit unclear on the scope of this project

[11:07pm] eekim: say more

[11:08pm] TimStarling: well, she asked me some technical questions

[11:08pm] Bair joined the chat room.

[11:09pm] TimStarling: and some of those technical questions were the sort of thing which would more often be answered by a software engineering team in the course of their normal design process

[11:10pm] eekim: such as?

[11:10pm] DanielB left the chat room. ("Leaving")

[11:10pm] Philippe|Wiki: Hmm... eekim, didn't she have a large role in software design at a Big-5 company? Perhaps she's asking those because those are the ones she's most comfortable with? I'm truly speculating here, though, and that's probably not wise.

[11:11pm] eekim: she worked at palm, but she had nothing to do with software

[11:11pm] Philippe|Wiki: Ah, my bad.

[11:12pm] apergos joined the chat room.

[11:12pm] eekim: hey apergos!

[11:12pm] _sj_: go danielb go

[11:12pm] apergos: just lurking

[11:12pm] Bair: could someone please /MSG me the 21:00-21:09 log so I can get a clue about the context?

[11:12pm] Philippe|Wiki: Bair: sure

[11:13pm] eekim: lurk away

[11:13pm] _sj_: TimStarling, how are normal design process questions answered now?

[11:14pm] Bair: TimStarling: what was Serita asking about?

[11:14pm] _sj_: TimStarling, a related strategy question I have is how we can better support our network of tech contributors

[11:14pm] TimStarling: _sj_: well, by consensus of the tech team under the leadership of the CTO

[11:14pm] _sj_: (was having a technical committee helpful? how can we provide more direct technical input to high level decisions, as domas has suggested we need to increase? &c)

[11:15pm] TimStarling: just as fundraising questions are decided by the fundraising staff

[11:15pm] _sj_: ah, the confusion is that she was directly/privately asking these questions, rather than finding a way to poll existing specs/roadmaps? was this a research question?

[11:16pm] Bair: one thing that would be really helpful is to figure out how to move the stuff in http://strategy.wikimedia.org/wiki/Template:Call_for_proposals#New_features to http://bugzilla.wikimedia.org/

[11:16pm] TimStarling: I'm not here to talk about what she asked me, I'm here to ask what you think the scope of the strategy project is

[11:16pm] _sj_: I would expect that fundraising questions will be asked directly of people involved by the fundraising task force

[11:16pm] _sj_: and similarly for tech questions

[11:17pm] TimStarling: I'm just concerned that nobody with any kind of technical talent will be on this task force

[11:17pm] eekim: the scope is wikimedia-wide looking five years down the line

[11:17pm] _sj_: as research inputs to the TF's who are compiling existing plans, projects, risks, opportunities, and existing proposed solutions

[11:17pm] _sj_: (or novel proposed solutions if none exist -- we haven't really addressed the question of OR in the context of TFs)

[11:17pm] eekim: i've been heavily recruiting brion

[11:17pm] eekim: you can help with that, tim

[11:17pm] eekim: and you can participate on it also

[11:17pm] TimStarling: and that the decisions thus taken will be ignored by people with more clue

[11:18pm] _sj_: TimStarling: what decisions?

[11:18pm] TimStarling: well, that's what I'm asking

[11:18pm] _sj_: TF's don't make decisions. they do research and compile reports.

[11:19pm] eekim: tim, you haven't really asked anything so far

[11:19pm] eekim: current tech-related questions are captured at: http://strategy.wikimedia.org/wiki/Optimize_Wikimedia%27s_operations#Technology_Infrastructure_Task_Force

[11:19pm] TimStarling: strange then that _sj_ is giving me answers

[11:20pm] Bair: there should be standards. If the technical process isn't based on interoperable (which means platform independent, mostly, for media wiki) code then it's likely damaged and should be routed around. Similarly, if the content proposals aren't showing respect for quality, then the peer-to-peer proposal should be accelerated

[11:20pm] _sj_: (as far as I can tell, that is. this isn't my personal favorite set of jargon. I have the impression that there is some shared notion of 'task force' in the world of strategic planners, but we're free to recreate what it means in the context of our comunity.)

[11:20pm] eekim: sj is apparently a mind-reader

[11:20pm] _sj_: bair: agreed on moving features to bugzilla

[11:20pm] eekim: help me out here

[11:20pm] Amgine: I think you're wrong, eekim. I too understood exactly what TimStarling was asking.

[11:20pm] Philippe|Wiki: _sj_ and Bair: I think that's sort of always been the idea, but we simply haven't gotten there yet

[11:20pm] _sj_: bair: your last comment is pretty specific. you might want to write that down as an essay on a wiki page...

[11:21pm] eekim: Amgine, fair enough. can you repeat the question?

[11:21pm] Amgine: Is strategy making an end run around the Dev monopoly on software goals/development.

[11:22pm] eekim: thanks, amgine

[11:22pm] Amgine: Can Strategy tell Devs what to do?

[11:22pm] Bair: there was a dev monopoly?

[11:22pm] eekim: if devs don't participate in strategy, then it's not a very useful process

[11:22pm] Amgine: I don't know, Bair.

[11:22pm] • _sj_ has to go get some quinoa or he will mulch where he sits

[11:22pm] TimStarling: it's not so much bad goals I'm worried about, it's bad implementation details

[11:23pm] _sj_: TimStarling: my opinion is that the outcome of the strategy process should be light on implementation details

[11:23pm] eekim: so there's a problem with the basic premise of these questions that we need to clear up

[11:23pm] _sj_: but should help focus and organize a large set of independent ideas, priorities, and partial plans

[11:23pm] Amgine: <grin> I recall two meetings ago also asking about the scope of Strategy...

[11:24pm] eekim: with wikimedia, everything is interrelated, tech included

[11:24pm] _sj_: provide a basis of research on which any group within the community can develop its own internal strategy

[11:24pm] Bair: anyone can propose at bugzilla or even WP:VPT, and other people carry the ideas forward if they approve. The call for proposals resulted in a bunch of things which would ordinarily start at one of those places, but that's okay because those were stagnant as the usability initiative showed after it got going, and the pace has picked up, yay. But is it sustainable?

[11:24pm] eekim: the questions we've been asking have been high-level

[11:24pm] eekim: where should wikimedia be in five years?

[11:24pm] _sj_: (so for instance the tech team should be able to draw on the work done by task forces and other parts of the next few months of strategy work, in addition to contributing to it, to form its own strategy)

[11:25pm] TimStarling: I think the tech team does need guidance on priorities

[11:25pm] eekim: absolutely

[11:25pm] eekim: and the tech team needs to communicate its needs as well

[11:25pm] TimStarling: things like required features, and their likely impact

[11:25pm] eekim: also what's possible

[11:25pm] eekim: communication needs to be two way

[11:26pm] TimStarling: but I don't think the tech team needs guidance on what programming languages it should use

[11:26pm] _sj_: and that at the end of ~10 months of strategy, while many subgroups will still need to develop their own strategic plans, there will be a broad 5-year strategy adopted by WMF

[11:26pm] eekim: totally agree with that

[11:26pm] eekim: y'all should be using python

[11:27pm] eekim: take advantage of this space to do some of your own strategic planning

[11:27pm] apergos: don;t make me have to stab you

[11:27pm] Bair: how many coders need to be hired to make sustainably-increasing levels of progress on the meritorious technical proposals, wherever they happen to be written down?

[11:27pm] apergos: it will look bad in the logs

[11:27pm] • eekim puts on asbestos suit

[11:27pm] _sj_: yesterday I rewrote the mediawiki parser in haskell again. it's still not faster.

[11:27pm] eekim: here's a very simple mid-level strategic question

[11:28pm] eekim: how many devs should WMF have on staff?

[11:28pm] TimStarling: 200

[11:28pm] _sj_: (sorry, that was a quote from someone standing here who did not in fact do such a thing

[11:28pm] Bair: more than they have in the past

[11:28pm] TimStarling: but fundraising may provide some limitations there

[11:28pm] eekim: that number still puts you an order of magnitude behind the other top five web sites

[11:28pm] Amgine: enough to maintain code and make progress on all technical projects.

[11:28pm] Bair: at what point in time, given present levels of financial growth, is sustaining 200 coders feasible?

[11:29pm] Amgine: How many angels dance on a pin head?

[11:29pm] _sj_: amgine: all proposed projects? all active projects? all possible projects if we pursued all types and scopes of collaborative content creation and distribution?

[11:29pm] apergos: in 20 years?

[11:29pm] Philippe|Wiki: Bair: that sort of depends on how much of that financial growth is directed there?

[11:29pm] eekim: what does 200 devs buy you that 100 does not?

[11:29pm] Philippe|Wiki: You can't assume a smooth curve in disbursement

[11:30pm] apergos: (we have data centers and hardware to go in them; this too will increase substantially over time)

[11:30pm] TimStarling: it's not all about the coders though, we would need to grow in all sorts of roles

[11:30pm] Amgine: _sj_: it's an equation, not a limiting description.

[11:30pm] eekim: right

[11:30pm] _sj_: aha

[11:30pm] Bair: once all the strategy feature proposals get on bugzilla, then you can set up the dependencies to do critical path analysis to create a pert or gant (sp?) chart (or a set of them all parallel to each other) which really helps planning coder headcount

[11:31pm] eekim: but the total headcount only answers part of the question, because mediawiki has volunteer devs also

[11:31pm] eekim: and could potentially attract a larger volunteer community

[11:31pm] eekim: which is another strategic question

[11:32pm] eekim: what could mediawiki be doing to attract a larger dev community? is that desirable? what would that accomplish?

[11:32pm] TimStarling: well, one thing I mentioned to serita is that we would have more community developers if we paid technical writers to improve the manuals

[11:32pm] Bair: coders need managers, who among other things need skill in hiring and leadership and social skill... there's administrative and physical plant overhead too, and growing at a certain overall rate would typically be decided by the highest levels of leadership

[11:32pm] Philippe|Wiki: interesting, TimStarling ...I like that.

[11:32pm] eekim: now we're talking

[11:33pm] eekim: hiring tech writers and other support roles (QA for example) may give you greater returns than hiring devs, because it attracts a stronger dev community

[11:33pm] Bair: paid technical writers, that would be a good proposal which probably didn't make it in. Maybe you can fold it into the hire translators proposals

[11:33pm] _sj_: also <book sprints> and <featured manual/help content>

[11:33pm] Philippe|Wiki: Bair: proposals are still welcome

[11:33pm] eekim: absolutely, sj

[11:33pm] TimStarling: that's not much of a proposal by itself though

[11:34pm] eekim: nope, but it's a start

[11:34pm] _sj_: gantt chart : would be interesting to see

[11:34pm] eekim: lots of open source companies have full-time dev evangelists

[11:34pm] apergos: "hire nika and siebrand" was a pretty short proposal too

[11:34pm] eekim: should WMF hire one of those?

[11:34pm] Bair: yeah, QA is important too, but I can say from first-hand experience that volunteers can get discouraged when their efforts at QA aren't appreciated

[11:34pm] TimStarling: nika?

[11:34pm] eekim: i hear you, Bair

[11:34pm] apergos: nikerabbit

[11:34pm] _sj_: nike

[11:34pm] Amgine: <checks clock> Is this scheduled for 0300?

[11:34pm] Bair: there's another one Proposal:Translators which is more general and wide-ranging

[11:35pm] • _sj_ is away for a bit

[11:35pm] Bair: sorry http://strategy.wikimedia.org/wiki/Proposal:Translator

[11:35pm] TimStarling: niklas is doing a masters, he can't work full time

[11:35pm] apergos: nope, but siebrand is now on a contract for 1 day a week.

[11:35pm] eekim: the proposals vary in levels of feasibility

[11:36pm] apergos: small steps but valuable

[11:36pm] TimStarling: anyway, a separate QA department is a controversial topic in software engineering at the moment

[11:36pm] eekim: exactly

[11:36pm] Bair: http://strategy.wikimedia.org/w/index.php?title=Proposal:Translator&diff=30177&oldid=29950

[11:36pm] TimStarling: the agile movement has it that they are toxic and should all be disbanded

[11:36pm] Philippe|Wiki: Amgine: scheduled for 04:00

[11:36pm] Amgine: kk

[11:36pm] eekim: agile also endorses stronger test frameworks

[11:37pm] eekim: how strong is our framework?

[11:37pm] eekim: what sort of coverage do we have?

[11:37pm] Philippe|Wiki: Amgine and I have 04:36

[11:37pm] TimStarling: yes, written and operated by the developers who write the bulk of the code

[11:37pm] eekim: exactly

[11:37pm] TimStarling: agile says that testing should be everyone's responsibility

[11:37pm] Bair: TimStarling: really?!? my agile gurus are always stressing backing up sw tests with headcount testers, especially in net gear

[11:38pm] eekim: Bair, do your gurus suggest that devs should not be doing tests?

[11:38pm] Bair: there's a lot of crap that automated tests won't catch but brains will, but that doesn't matter so much in the mediawiki fishbowl, where reviewers ("users") are always a given

[11:38pm] Bair: devs should definetly do tests

[11:38pm] apergos: is this something we should be trying to decide here right now? or just flagging it for later discussion?

[11:39pm] TimStarling: I would also add UI design as a separate role, and DBA

[11:39pm] Bair: agreed

[11:39pm] eekim: maybe so, but regression testing buy you some measure of confidence that you can't get from manual testing alone

[11:39pm] eekim: much better for refactoring

[11:40pm] eekim: apergos, we're not deciding anything right now

[11:40pm] eekim: just trying to ask the right questions, understand the challenges better

[11:40pm] apergos: ok. so maybe flag qa as an area for discussion then

[11:40pm] Philippe|Wiki: apergos: Done

[11:41pm] eekim: my guess is that most devs have an opinion on all of these things

[11:41pm] Bair: actual users who are depending on you to solve real problems are better than a QA department, but not all devs have the luxury of a huge user base... well, actually I should say not all projects, because it's not specific to individual devs

[11:41pm] eekim: this is a great opportunity to capture those opinions

[11:42pm] eekim: if there's a high-level of agreement, then that tells us something

[11:42pm] eekim: if there's not, then there's an opportunity to get to that level of agreement

[11:42pm] eekim: Bair, we're definitely lucky to have an enormous user base

[11:43pm] eekim: so here's another mid-level question

[11:43pm] Bair: I like the idea of hiring 200 coders. Could the Foundation reasonably raise $50M/year?

[11:43pm] eekim: open source projects do not have a great track record for integrating usability into their processes

[11:43pm] eekim: but there are some success stories

[11:44pm] eekim: assuming usability is a high priority, what steps should we be taking to support that

[11:44pm] TimStarling: well, it can be dealt with at the code review stage

[11:44pm] • Philippe|Wiki grumbles about a certain opensource project management tool that eekim is fond of...usability appears to be an afterthought

[11:44pm] eekim: nope

[11:45pm] Bair: see above, the usability on small internet devices increased hugely after you started hiring people to work on them

[11:45pm] eekim: usability is like security

[11:45pm] eekim: you can't wait until code review to do it right

[11:45pm] eekim: you have to think about it right from the start

[11:45pm] TimStarling: we deal with security at the code review stage

[11:45pm] eekim: really? you don't think about security at all at the design stage?

[11:45pm] TimStarling: have you seen our web page?

[11:45pm] TimStarling: http://www.mediawiki.org/wiki/Special:Code/MediaWiki

[11:46pm] TimStarling: we have an unstable insecure trunk, then review code submissions before they're merged to a release branch

[11:46pm] Bair: I remember how long it used to take to load Monobook on a WinCE PocketIE around 2005, lol

[11:46pm] TimStarling: volunteers don't have a design stage, they just dump code on you

[11:47pm] TimStarling: at which point you have the opportunity to give them some pointers

[11:47pm] eekim: for lots of code, yes

[11:47pm] eekim: but what about things like unified login?

[11:47pm] eekim: i assume those features were designed first

[11:47pm] TimStarling: sure

[11:47pm] eekim: and i assume that in that process, you thought about security in advance

[11:47pm] eekim: as well as in the code review process

[11:48pm] Bair: those ARM processors still have 32 kiloword caches and they've typically stayed around ~400 MHz to save battery life, so actually hiring people to take out the stuff that rendered slow was a huge win

[11:48pm] TimStarling: anyway, I've written a short document about security, mostly for volunteers

[11:48pm] TimStarling: if someone was actually reporting to me I'd get them to read it before they wrote any code

[11:48pm] Amgine: linky?

[11:48pm] TimStarling: but in practice the opportunity to make them read it comes when I'm reverting their code for poor security

[11:48pm] eekim: if people rtfm, the world would definitely be a better place

[11:48pm] TimStarling: http://www.mediawiki.org/wiki/Security_for_developers

[11:49pm] Amgine: merci.

[11:49pm] TimStarling: I'm saying that we could have a similar practice for usability

[11:49pm] eekim: there are usability issues that are incremental that can be fixed at the code review stage

[11:49pm] Philippe|Wiki: eekim: that speakes to Tim's point about tfm always being readable too....

[11:49pm] eekim: but there are fundamental issues that need to be addressed at the design stage

[11:49pm] eekim: workflow, for example

[11:49pm] eekim: that's not something you can easily patch

[11:51pm] TimStarling: on a broader level, the way to fix usability is to hire people who know/care about usability and get them to talk to devs

[11:51pm] eekim: that's definitely one approach

[11:51pm] TimStarling: when there's a design stage that we have access to, they can give input there

[11:51pm] TimStarling: if not, they can give input at the review stage

[11:51pm] eekim: my question is, is there an opportunity to attract volunteer usability folks?

[11:52pm] eekim: there is some precedence

[11:52pm] eekim: firefox has a hybrid model

[11:52pm] eekim: they employ lots of awesome usability folks, but they've also gotten tremendous contributions

[11:52pm] TimStarling: sure

[11:53pm] eekim: per sj's point earlier, one of the things that should happen in this process is research and aggregation of models that we can learn from

[11:53pm] eekim: here's an opportunity to have conversations with folks like alex faaborg at mozilla

[11:54pm] eekim: i hope that devs see this as an opportunity to have the kinds of conversations they'd like to have and raise the overall cluefulness of the entire community

[11:54pm] eekim: and i want to do everything i can to support that

[11:55pm] TimStarling: sometimes it's hard to make devs care about usability

[11:55pm] eekim: definitely

[11:55pm] Bair: WP:VPT is filled with usability volunteers, active and willing both, but without effective organization and management, they are forced to be reactive instead of participating in the problem solving. But there really is a huge outlay of time involved in such participation, so actually hiring is better than depending on volunteers to accomplish set goals

[11:55pm] eekim: fair point

[11:55pm] TimStarling: usable code can take quite a lot longer to develop than the bare feature that the dev is naturally inclined to

[11:56pm] eekim: i think we can start by hiring, then start thinking about involving others

[11:56pm] eekim: Tim, absolutely

[11:56pm] eekim: the tagline in open source is scratch your own itch

[11:56pm] TimStarling: it's a higher point on scale of quality, than just barely working

[11:56pm] eekim: the tagline in usability is, you are not your user

[11:56pm] eekim: those two concepts are fundamentally contradictory

[11:57pm] eekim: which is a big reason why we don't see usability more deeply embedded in open source

[11:57pm] TimStarling: so I think having coders who are encouraged via their supervisors to think about usability is helpful

[11:57pm] TimStarling: paid coders, that is

[11:57pm] eekim: i agree with that

[11:59pm] Bair: the most organized volunteer usability people are the bot coders, who just do their remote thing and suddenly all the interwikis follow renames or whatever

[12:00am] Bair: that's why I like the peer-to-peer model so much, it's amenable to fork-and-merge better, because that's what the underlying databases are doing when they synch up

[12:02am] eekim: are you talking about the network level?

[12:04am] eekim: folks, i need to check out

[12:04am] Bair: I mean, the code base under a p2p regime is more likely to work with organic mix-and-match feature sets, because the coders think in terms of a bundled client and server, with the database being synched ...

[12:04am] eekim: tim, bair, amgine, apergos, excellent talking to you all

[12:04am] Bair: thanks, eekim

[12:04am] eekim: strongly encourage you to take a look at the tech stuff on the strategy wiki

[12:04am] eekim: keep the rest of us honest

[12:05am] eekim: and i want to explore ways that we can get y'all to participate more actively

[12:05am] Bair: I'm not opposed to a monolithic mothership server, by the way!

[12:05am] eekim: *laugh*

[12:05am] Philippe|Wiki: Only if it can look like the UN bldg....

[12:05am] apergos: death star

[12:05am] apergos: or it ain't happening

[12:05am] Bair: it's a reasonable default thing to synch against. I just hope it stays high quality to keep interpeer patches to it small

[12:05am] eekim: on that note, i'll talk to y'all later

[12:06am] Philippe|Wiki: nite eek

[12:06am] TimStarling: just screw things up, then I'll feel obliged to participate

[12:06am] apergos:

[12:06am] • Philippe|Wiki notes Tim's request

[12:06am] Bair: we already have a monolithic server architecture

[12:06am] eekim: that can be arranged, tim

[12:06am] eekim: night everybody

[12:06am] Amgine: <questions "can">

[12:06am] TimStarling: night

[12:06am] eekim left the chat room. ("Leaving")

[12:07am] _sj_: re

[12:07am] Philippe|Wiki: Bair, ping on your DM

[12:08am] Amgine: rehi _sj_

[12:08am] Philippe|Wiki: Likewise, it's midnight for me. I'm going to post this log and go find a nice warm bed.

[12:08am] Philippe|Wiki: ********* END LOG *********