Hi all,
I'm posting this to d-d-a since it doesn't make sense to me to answer
questions in a different forum to where they've been raised. It's already
been pointed out [0] that this sort of discussion isn't appropriate for
-devel-announce, so I'll try to keep it brief. Followups to -project
[1], please.
[0] http://lists.debian.org/debian-project/2006/10/msg00264.html
http://lists.debian.org/debian-project/2006/10/msg00266.html
http://lists.debian.org/debian-project/2006/10/msg00269.html
http://lists.debian.org/debian-project/2006/10/msg00273.html
[1] http://lists.debian.org/debian-project/2006/10/msg00260.html
Beyond this mail, I won't be posting any further about Dunc-Tank on Debian
lists. Debian's lists are for improving Debian, not for discussions about
other projects, and counting this mail, Dunc-Tank has had eight messages
on -devel-announce, over a thousand messages in various threads on other
lists, along with a large number of posts on Planet Debian. While people
are free to discuss whatever they want, I personally don't think the
Dunc-Tank project is that much more important than other parts of Debian
to warrant such a huge focus, so I won't be a part of those discussions
on Debian lists.
On Thu, Oct 26, 2006 at 07:46:00PM +0200, Joerg Jaspert wrote:
> - Why were the release managers (RMs) chosen as [participants] for this
> experiment?
There are three aspects required for funding free software in this sort
of manner that line up well for release management at the moment.
The first is we already have people who have been working on release
management in an unpaid manner, who are able to take it on as a full
time task at short notice. This avoids the difficult tasks of recruiting
people with the appropriate skills and motivation, and dealing with the
possibility that they may, in fact, not have the skills they claimed,
or turn out not to be as interested as they thought; or having to worry
about people who aren't familiar with contract work having to become
familiar with it (in particular the tax and reporting requirements
associated with it, and the issues of dealing with the risks associated
with not having any employment benefits, paid vacations or sick leave,
or a reliable salary and requirements that your employer give notice
before you have to go job hunting).
The second is that as a task, release management has a defined end point,
with the release of etch giving a very clear point at which we can stop
funding people and work out what to do next, without risking any harm to
the release process in general, since the release team are expecting to
take a break after etch is out anyway. In addition, release management
work becomes significantly more effort as the release date approaches,
which makes a time-limited experiment at the end of the release cycle
make much more sense than a similar experiment would on a task that needs
to continue on an ongoing basis, such as security support or development
of packages in unstable.
The third is that release management is widely recognised as an important
and timely issue for Debian by our users at the moment. That's important
not only in and of itself, but it also makes it more likely that users
will be willing to say "I can't help fix any of the bugs and I don't
have any time to do testing and such, but I'd be happy to donate some
money on this, because I think it's important".
There are likely other projects where all of those aspects apply,
but in my opinion, right now, release management is the one where they
apply best.
> There are several areas within the Debian project
> that we consider equally important and full-time work there could
> benefit the project way more.
Dunc-Tank is operating through the Public Software Fund [2], which
allows people to fund any free software development activities through
donations (which are tax deductible in the US), so there's absolutely
nothing stopping any of those projects being funded in the same way. To
the best of my knowledge, no one has asked for support from either myself
(as DPL) or the Dunc-Tank board or given details of other such projects
or how funding would help them.
[2] http://www.pubsoft.org/
https://www.pubsoft.org/pubsoft.py/how-funding
https://www.pubsoft.org/pubsoft.py/philosophy
https://www.pubsoft.org/pubsoft.py/determination
> - What exactly are the release managers being paid for? There surely
> must be more than a simple "Stay at home, work on Debian" in their
> contract.
They're not required to stay at home. :)
The principles we're using for Steve's work primarily relies on mutual
trust rather than nailing down too many details:
(1) Steve will work full-time on release management tasks
for etch, beginning Thursday 12th October, ending Monday
13th November.
"Full-time" is intended to be equivalent to at least 8-10
hours per day, 5 days per week to the exclusion of other
employment
(2) "Release management" tasks involves anything related to
ensuring that the etch release meets the standards set
for it. Primarily, this means being of at least as high
a quality as previous stable releases; secondarily, this
means meeting the release team's stated goal of delivering
etch on the 4th of December 2006; and thirdly, this means
enabling the project to meet as many additional release
goals with etch as possible.
(3) Steve will provide at least two reports to the board (and
anyone else he thinks may be interested) briefly describing
how this project has affected his RM tasks, once on or
after the 27th of October, and once on or after the 13th
of November.
This requirement is expected to be met by Steve blogging
details of his work roughly three times per week.
(4) Dunc-Tank will provide $3,000 USD mid-way through October and
a further $3,000 USD in the middle of November upon receipt
of the reports mentioned in point (3).
(5) This will be considered payment for a service, not
employment, and Steve will take responsibility for any tax
considerations that result from this. No other benefits
will be construed to arise from this contract.
Note that going through the Public Software Fund implies that anyone
may bid to work on any project that is proposed, simply by logging in
through the website.
> - How does DT want to know whether the release managers stick to their
> part of the agreement?
We'll be reviewing Steve's progress after the mid-point and end-point,
and using that information to make suggestions for both Steve and Andi.
> - How is the success of this "experiment" measured? (For the release as
> well as for the entire project)
An "experiment" is successful as long as it provides useful information.
Whether Dunc-Tank will continue or adopt any other projects or similar
will be decided after the release of etch, by the Dunc-Tank board or
whatever process the Dunc-Tank board defines. Whether anyone else does
anything similar will be decided by whoever wants to do anything similar.
> - What actions have been taken to ensure that potential negative
> outcomes of the experiment won't affect the Debian project?
The Debian project has a number of checks and balances already in place
to ensure that useful activity isn't blocked.
> - During the discussion before the experiment it was said that the
> living costs of the release managers are to be paid.
When originally proposing this as something that SPI should do with existing
Debian funds, I wrote:
] * I haven't gone into specifics about the amount deliberately. I will
] later. I've discussed appropriate amounts with Steve McIntyre, and
] Bdale Garbee, and the range we thought was appropriate and feasible
] more or less matched the range that Steve and Andi need and expect
] for a month's employment. If you're used to hiring IT contractors in
] the US or UK, it'll probably seem absurdly cheap; if you're a broke
] student or from a less wealthy country, it might well seem absurdly
] expensive. The exact figure is still not entirely determined since
] we're not 100% clear on how to handle the tax requirements yet. It
] well and truly leaves Debian with enough funds held by SPI to buy
] replacement parts and do other things it might need to, fwiw.
Money is a sensitive subject, and any reasonable figure will be seen
as ridiculously high by some, and amazingly low by others. The amount
in this case is determined by the Dunc-Tank board as reasonable both
considering the work being undertaken and the amount that people would
be willing to contribute. As this isn't a Debian project, beyond the
above no further consultation on the amount was undertaken with Debian
developers. In my personal opinion, I think that amount is entirely
reasonable for a full time commitment to a fairly wide range of Debian
tasks. Others may value those tasks higher or lower, of course.
I've deliberately skipped a number of questions here, largely on the
basis that I don't think it's appropriate to commit to answers to them at
this time. Likewise, I'm not going to presume to comment on any claimed
experimental results while the activities under discussion remain ongoing.
> Although DT claims to be separate from Debian, we still feel that we are
> entitled to an answer to our questions, since after all, we are the
> people DT is experimenting with!
Dunc-Tank exercises absolutely no control over Debian, and imposes
absolutely no obligation on anyone involved in Debian. Allowing its
existence or actions to influence you is entirely optional.
I'd encourage people both pro- and anti- Dunc-Tank to consider the advice
of http://www.donotfeedtheenergybeast.com/ and whether continuing to
publicise and debate the topic actually aids your goals.
Cheers,
aj
Attachment:
signature.asc
Description: Digital signature