On Fri, 28 Mar 2014, Tibor Simko wrote:
Good idea for those teams who are undecided; but please set deadline
to today, not to 7 days from now, because we thought of completing the
first selection round today.
(And please note that we are doing only first-round voting today, not
the final selection; so there will be time to reiterate. Unless some
top candidate would be agreed upon in the first round already, as in
any real presidential election.)
I note that some people from our corridor (Jiri, Lars, and friends)
also voted. This is not necessary, because the votes from our CERN-IT
teams were already expressed. (I see that the CDS team has voted as
well.) If tricider is to express the opinion of the INSPIRE team,
then these votes are only clouding your picture, as it were.
Some people have been wondering why I proposed to express our opinions
by teams or units in the first selection round of our next ticketing
and merging tool. So I thought I express my thoughts briefly here.
Firstly, Invenio developer community consists of about 40 people
committing code per year. We are naturally and organically organised in
teams that work on different topics, say the multimedia team or the
author disambiguation team. It is natural that people within given
teams talk to each other more frequently than with outside teams, and
that each team probably has their opinion on what tools (merging,
ticketing, etc) would advance their work the best. I'd call this
intra-team communication.
Secondly, the teams are not living in a vacuum. We have very fruitful
collaboration between various teams and units, and Invenio would never
look the way it does now without our cooperation. Examples are
numerous, say the task scheduler improvements brought by INSPIRE
operations, or Solr indexing and ranking improvements brought by CDS
operations. I'd call this inter-team communication.
In order to coordinate our intra-team and inter-team ideas about our
project, technology, services, and whatnot, we have several channels in
place. One of them being Invenio Developer Forum on Mondays where we
muse about common greater good. From time to time we pause and think
of sharpening our saws. As happened a few years ago for the selection
of Flask framework, later on for the selection of the Twitter Bootstrap
UI framework, then last summer for the selection of JS MVC framework
(which is still kind of on hold). Now we are trying to select our
ticketing and merging framework. Usually we do this by inter-team
discussions and intra-team discussions to see if a consensus emerges.
It would be hard to do otherwise.
Thirdly, the INSPIRE team proposed an (internal) doodling process to
express everyone's opinions in a numerically quantifiable way. I'm not
sure this is the best way to go about it. Consider a team of developers
A, B, C, D, and E. Consider that A does on average 2 pull requests per
month, while B does 10. What do we do? Shall we express their opinions
numerically by head-count? (This is what doodling does.) Isn't it more
representative to weight the opinion of respective developers by a
factor of 5x, since B uses the tool five times more on average than A?
Now consider developer C who also commits 2 times per month, but instead
of committing 500 LOCs on average as A and B do, she commits 2500 LOCs.
Again, shall we apply a correction factor? Will it be 5x? How do we
weight the number of pull requests vs the number of lines of code? Now
consider developer D who reviews code on average 5x more than A-C. How
do we numerically factor his own use case? And what about developer E
who also reviews code a lot, but only twice per month. Will his opinion
count less? E works on the most difficult tasks and hence has possibly
5x more review annotations on average then the rest of the team. Shall
we increase the weight behind his opinion? And how do we balance coding
amount vs pull request issuing amount vs code reviewing amount against
each other, when choosing a common tool?
This was just to illustrate various difficulties that come along when
expressing votes numerically. Ditto for people doing triaging more
than others, ditto for people doing documentation more than others, etc.
We could aim for a matrix, but would this be the right approach?
So it was these kind of considerations that brought me to propose to
register our first selection round results by sub-teams or sub-units
we are composed of organically; simply because this addresses my first
point (=intra-team communication) and also covers to some extent my
third point (because different developer styles, from A to E, are
usually found within given team). But I also reckon that such a
results-by-sub-units representation has a major drawback: it does not
cover very nicely my second point (=inter-team communication). However,
since this communication was happening organically since autumn on the
corridors, and formally during our Monday fora since
