"official" MOTU projects (was: Morgue for MOTU ?)

Stephan Hermann sh at sourcecode.de
Sat Feb 11 12:56:50 GMT 2006


Hi,

On Saturday 11 February 2006 12:07, Reinhard Tartler wrote:
> Stephan Hermann wrote:
> >> No, you can't *force* a volunteer to do anything.  That's not the same
> >> thing as "no expectations".  I think it's reasonable to set a number of
> >> expectations of MOTUs, document them, and then require that, if you want
> >> to be part of the team, that you abide by those expectations.  If you
> >> are unwilling or unable to meet the necesary expectations, it's "thanks
> >> for your contributions, but you're off the team".
> >
> > You can't force or expect anything from someone. The volunteer is
> > starting his work because he wants to. He will end his work, because he
> > wants to, has no time anymore or whatever reason he has.
>
> This way auxiliary fire brigade would never work. But TTBOMK it does.

1. No. It doesn't. 2. Yes. It does.

Point 1: As far as I know is the first reason to join the auxiliary fire 
brigades for a long time, to not join the armed forces (in Germany), just 
like the "Technisches Hilfswerk".

Point 2: There are always people who wants to join those organisations to help 
other people because these people want to do it, but they can leave after a 
special ammount of time those organisation.


> > The Ubuntu way of handling this is, document your work, become a Member,
> > and after some time, become an ubuntu-dev with universe/multiverse upload
> > rights. The Ubuntu / ubuntu-dev membership won't last forever, they are
> > limited to 1 to 2 years. If they're not renewed you loose your rights
> > automatically. Thx to LP.
>
> I think this will become a serious problem in perhaps one or two years.

Well, I don't think so.
To be precise: You start normally to work on these projects in your time, when 
you are still in university, and when you have a little more time then other 
people who are working in jobs where time is limited (including kids, wife 
etc.)
So, you have a lot of young people doing a great job for opensource projects, 
and you have only a small ammount of "older" people, who are working on those 
projects (and they're doing a great job too).
Or you work for a company llike Novell, RedHat, Canonical, MySQL etc. and do 
opensource stuff for a living.

The university/young people are quite interested in opensource, which is good, 
but many of these people are leaving or switching projects quite fast. What I 
saw in my years is, that the average time of being part of a project is 
between 1 and 2 years. And right, there is no rule without exception.

Other people, like me, are doing the work (as volunteer) because they are 
interested in doing opensource work. But the time working on this is limited, 
because of real life work, kids and wife and other responsibilities.
So, there is always a "big boom bang" when those people like me are coming and 
doing something, but this "big boom bang" can go away quite fast (6 months to 
1 year). 
(Regarding Ubuntu) We saw that earlier during breezy and now for dapper. And I 
see now for myself, that my time is limited doing some stuff, because I'm 
busy finding a job and I have to do jobs, I never imagined I would do. 

But we actually do something, even when it's not so much anymore then before.

So the timeframe for loosing upload-rights of 1-2 years, without renewal, is 
quite useful. It helps to clean the people from the list, which are not 
interested anymore, switched projects or actually don't have the time 
anymore. 
They are still able to apply for those rights again, when they have the time 
to do more.

And again, there is no rule without exception.

> > This is different from Debian, where someone has to write a lot of emails
> > and waiting for no response to set the maintainer as MIA.
>
> ?? - Did you have to write a lot of emails? The correct procedure
> handling inactive Maintainers in Debian is documented here:
> http://www.debian.org/doc/developers-reference/ch-beyond-pkging.en.html#s-m
>ia-qa
>
> Something we have not (yet) documented, but I think we should do so.

Quote from MIA handling: 
"
The first step is to politely contact the maintainer, and wait for a response 
for a reasonable time. It is quite hard to define "reasonable time", but it 
is important to take into account that real life is sometimes very hectic. 
One way to handle this would be to send a reminder after two weeks. 

 If the maintainer doesn't reply within four weeks (a month), one can assume 
that a response will probably not happen. If that happens, you should 
investigate further, and try to gather as much useful information about the 
maintainer in question as possible. This includes:
"

So my "a lot of emails" is a bit misunderstanding. But the system differs in 
this, that this decision is being made of another member of the debian 
community then myself.

It's right, the other member has to check various sources if I'm (when I'm a 
debian package maintainer) really MIA. It includes:

- Checking internal debian databases
- Checking how many RC bugs or outstanding bugs the package has, and
- Checking other sources, where I might be responsive.

Doing this MIA check leaves me a bad taste on my tounge, because 1 and 2 can 
be automatically checked, but the last point there is no "real" way how to 
achieve it, because how do anyone know, on which MLs or forums I'm on?
Furthermore, there is know way documented that the MIA people are 
"re-checking" the correctness of the data (which can't be gathered 
automatically) which was send to them.

But these views are coming from a system which works for "one maintainer one 
package" (where one package is wrong but you know what I mean)

Ubuntu works different. The team is responsible for the packages they are 
working on, not a single individual. Therefore, if one member of this team is 
missing, others will join, and the other members will catch up at all with 
their work.

So the only one who is responsible for his own rights to upload or do whatever 
he/she is doing, is {him,her}self.

> >> "No expectations" is, IMO, one of the leading causes of problems in
> >> volunteer organisations.  Nobody feels a need to do anything beyond
> >> "because I want to at the moment", and things fall apart.  In the larger
> >> context, society works on expectations -- courtesy, norms, and so on,
> >> are all expectations that society "in general" applies to it's members.
> >
> > That's right, and that's the reason why "volunteer only distribution"
> > will never succeed. Debian (as volunteer only org) will never see
> > officially supported commercial apps, but Ubuntu/Progeny/insert your
> > favorite (semi-commercial) debian derivative here, will see them.
>
> I strongly disagree. For me, debian is the most successful distribution
> on this planet, measuring the numbers of developers and users.
> Comercially supported applications is not one of the core goals from
> debian. You can read them here: http://www.us.debian.org/social_contract

I don't say that debian is not successful, quite the contrary, but for me as 
"distribution for a usage in an environment which needs reliability and full 
support", it's not working. As stated above, no rule without exception. 
Many people familiar with Debian and involved in Debian Development are using 
Debian in Datacenters etc. But when it comes to solutions for data mining and 
data storage, or other business related things (e.g. SAP) they won't get 
support and are on their own.

This is one of the reasons why Ubuntu is divided into two parts:

main/restricted, with all software in, which Ubuntu and their Canonical 
paid-devs can support, and universe/multiverse where all software is laying, 
which can't be supported easily because of several issues.

And this is why other commercially supported Debian based distributions are 
most likley to be chosen. 
To be honest, I actually don't know any commercially supported debian based 
distribtion, which is a supported environment for oracle or sap. Ubuntu could 
be the first and completly free available debian based distribution which 
could change this.

> Again something we don't have, but I think we should at least think
> about something comparable.

That's something the foundation has to do.

>
> > For me, volunteers are coming and are going. It's a continous flow of
> > "human resources" over time. Is that bad? No.
>
> This is how maintaining universe currently works. This is to me mainly
> because we have serious problems with the workload, and need as many
> volunteers as we can get.

That is one of the reasons why I don't like to do other jobs then doing my 
Ubuntu duty. We have enough workload to concentrate on our things, we don't 
have actually the time to do other people's work as well.
So every man and woman who are going to other projects, their energy is lost 
for Ubuntu. You can't concentrate on more then two things. And we all know 
that the involvement in one project will come with a deeper involvement in 
this projects, so not only uploading packages, or other things, but as well 
representing the project during fairs or having talks at LUG meetins etc. 
Being involved in N projects, it means to split my limited time T. 
It's simple: 4 projects and only 2 hours of time per day... 2/4 makes only 
half an hour per project. Which means 2 1/2h per week per project. Which is 
nothing. And 2 hours per day is a high value :)

But as I said before, people are coming and people are going, and there is 
always a way how to achieve the goal of making universe shiny at the end of 
the release cycle.

regards,

\sh



More information about the Ubuntu-motu mailing list