\documentclass[a4paper,10pt]{article}
%opening
\title{Are we really devoted to our users?}
\author{Margarita Manterola}

\begin{document}

\maketitle

\begin{abstract}
The Debian Social Contract, our most fundamental and distiguishing
document, states that {\it Our priorities are our users and
Free Software} and then says that {\it we will be guided by the needs of our
users and the free-software community}.  This talk intends to be an analysis on
the ways in which Debian as a whole is failing to have users as a priority and
also show some points were progress could be made.
\end{abstract}

\section{What the needs of our users are}

Saying that we want to take over the world is quite a normal statement among
the Free Software community.  Sometimes it's just a joke, but sometimes it's
serious, and what we actually mean is that we want to change the world, 
make it a better place for all, through the use of Free Software.

So, if we do plan to take over the world, we have to consider that 
{\it our users} are not just fellow developers, nor programmers or
sysadmins.
We have to take into account that {\it our users} might include office
secretaries, small-town homemakers, 10-year-old children, 80-year-old
grandmothers or maybe some third-world government officers.

So, when we say that we are going to be guided by the needs of our users, it's
really a very spread spectrum of {\bf needs} that we are supposed to be
considering. \\

This is not an easy task to achieve. Certainly, a task that needs constant
work and revision, since the needs of our users develop and change with time.

Yet while we face of the many difficulties that fulfilling our user's needs
present, it might be good to remember that many users are thankful of what
we do, that our efforts don't usually go unnoticed, and that when we help
to make someone's life easier we are one step ahead on taking over the world.

\section{How Debian is working on the users' needs}

Debian has always been an awesome distribution for the average sysadmin.  The
{\bf stable} concept has made Debian a very reliable option for those who need
a zero-downtime server.

Also, Debian has become a pretty nice distribution for the {\it
power-users}, those that like experimenting with hardware and software, those
that enjoy spending time in front of the computer, learning how to make it
work, and how to make it work better. 

But Debian is not yet being able to reach to the common users, those that
want the computer and the programs to {\it just work}, without having to
worry about configuration, administration or how the system works inside. \\

Many geeks I know would say that any person that does not intend to spend a
bunch of hours in front of the computer until it works as expected, is not
worth owning the box.  But we know better, don't we?

Maybe we do, maybe we don't. The fact is that we are lacking in many
user-related areas: hardware discovery, ease of use, internationalization, boot
time, general software speed, etc. \\

The effort made by the {\bf debian-installer} team in getting a fully
internationalized installer, really simple and intuitive is awesome. But
it's not enough, since after installing the whole system has to prove 
that it can be used and configured just as easily; and usually it doesn't.

\section{Reasons for our failing}

One of the main reasons in failing to meet user needs is probably 
that we don't use the same software that normal users do.  We use {\bf mutt}
instead of {\bf evolution} or {\bf thunderbird}, we use {\bf ion} or {\bf
window maker} instead of {\bf GNOME} or {\bf KDE}, we use {\bf vi} or {\bf
emacs} instead of {\bf OpenOffice.org}, etc.

Therefore, we don't really see what the users see. We don't care about those
pieces of software that we don't use.  \\

Also, we don't usually give the same importance to the programs a user
would care more about.  I.e. a library is more important than an end-user
application; a bug in an end-user application triggers it's removal from
the next-stable release, while a bug in a library that has dependencies
triggers someone actually fixing it. \\

Another one of the reasons in failing is that to become a Debian Developer, a
person has to handle enough English to be able to pass the NM process.  That's
good, but it's leaving behind a lot of people that don't speak English.

Since all DD's are required to understand English, we don't usually mind if a
certain menu does not turn up in our own language, because we understand
English, but a user that does not speak it will not understand the menus, and
that is an important flaw.  \\

In conclusion, the main reason of failing is that we don't put ourselves in
the users' shoes.  It's not like we should all go and start using evolution
because of this, but at least it's important to acknowledge that those
programs, no matter how ugly we find them, are a {\bf must} for the normal
users. 
And that {\bf l10n} bugs are not to be discarded as unimportant.


\section{What we could do to improve}

We have a QA team that has to make sure that all of Debian stays at {\bf Debian
quality}, but there are too many packages and too few people in the QA team, so
we -as developers, maintainers, users and human beings- have to work together,
to assure that all the distribution (not only our packages) has the highest
possible quality, and meets the needs of the broader user spectrum.

\subsection{Knowing what the users want}

We should really make more and more use of the popularity contest, so that
we can acknowledge the programs that have a bigger user base and work in
improving the quality of those.  Right now, popcon is not installed in
enough machines, the sample we have of the software installed is too
developeloper-biased, we need to acquire better knowledge of what programs
the users are really using.

If we knew what the users actually want, it would be easier to work on fixing
those programs, and making them {\it release ready} along the whole release
cycle.

\subsection{Internationalization}

It's important that we all make sure all the menus, docs, manpages, help
messages, etcetera are internationalized in as many languages as possible,
in as many packages as possible.  You might think that this is upstream's
responsibility, but since we are providing the programs to the users, we
{\bf need} to take the responsibility of making more complete translations
as well.

Also, we need to make sure that all the basic programs correctly support 
the many encodings that are out there.  This is to say, it's not sufficient
to support French, Portuguese, German or any other latin1 language.  We
have to make sure the whole system works in Japanese, Arabic or Vietnamese.
\\

This is a task that involves a larger group of people than just Debian
Developers.  There are language teams, and they usually work very hard to have
as much software translated as possible.  But when a maintainer ignores an l10n
patch that has been sitting in the BTS for months, it's not good for the
translators.

It's very important to acknowledge the works of the language teams, and treat
the l10n bugs as really important bugs, not as wishlists. \\

It's not difficult to change our approach about this matter, starting from
today.  If you maintain a package which is not translated, or not completely
translated, you should approach the language-team mailing-list and ask for
help, today.

This could, of course, be automated.  And the good thing is that we have
the skills needed to automate this process and make it easier for
everyone.  The only thing left is to do it.

\subsection{Documentation}

A very important thing that is missing from our distribution is to make the
information that is located in /usr/share/doc more accesible to the public.
Users tend to be clueless, not only because they tend not to read the
documentation, but also because they have no idea where it is.  

Tools like {\bf yelp} could help us.  Or anything that makes the information be
easy enough to find, no matter how newbie the user is. We need to integrate
them and make them part of the whole system.

\subsection{Package Management}

Since users need to install software into their boxes, we need to provide a
very simple way of doing it.

Simplifying Synaptic might be a way to do it.  Expanding tasksel (to
include a bit more granular tasks than today's) might be another.

The important point is to allow users to have a good, updated system, even
if they don't want to spend hours in front of their boxes tuning them up.

\subsection{Boot time}

Work in making the system boot and shutdown more quickly is desperately
needed.  This is specially important when trying to reach the 
double-booting public.

A freshly installed Debian system, with the common tasks selected, takes a
painful time to boot, and almost as much to shutdown.  This should be fixed
so that no processes are run at boot time when they are not really needed.

For example, exim is installed as a daemon even if the machine has no Internet
access, therefore it takes around one minute to timeout; hardware is
discovered again and again on every single boot; etc.
These are not so easy tasks to fix, yet we should at least have a goal of
decreasing boot time.

\subsection{Speed}

We have to work on making the programs run faster, on older hardware. 

Since we don't develop the software, but only package it, this is one of
the trickiest things. But we should keep in mind that not everyone in the
world has the money to buy a new machine with lots of RAM and a fast
processor.  And do as much as we can to increase the speed and decrease the
memory requirements of our software.

There are some things that we can do as a distribution.  For example, we
could include a different libc6 and a diferent libstdc++, and some other
libraries, for each model of processor (not just one per arch).

\subsection{Releases}

The fact that Debian should release more often is much more than well
known, and therefore will not be covered here.

However, it's important to keep in mind that we really need to think about
it and make it happen.

\section{How we could achieve these goals}

When presented with this many things to improve, it's difficult to find a
solution to all of them.  However, it's not impossible to think up some ways of
making progress for these areas.

\subsection{Set global goals}

Since working in a distribution is so different from working on a simple
application project, there's a general feeling that we can't set a global
goal.

We should leave that impression behind and set a global goal for us.  For
example: improve boot-time.  Many different packages need to be worked on
and changed to do this, so we need the collaboration of everyone involved.
It's a global goal that needs to be addressed as a team.  We {\bf can} do
it, we just need to have the initiative to go do it.

\subsection{Involve more people}

Many would agree that incorporating more than a thousand Debian Developers
is too many people to coordinate and to make sure that everyone is working
with the same quality of work in mind.

However, there are many ways of involving more people that do not mean
increasing the number of Debian Developers, just the number of
contributors.  Some of them are described in the next sections.

Accepting and organizing ways for more people to help us out, might be the
key of turning Debian into the universal distribution, or just staying at
one of the many distributions.

\subsection{Unify i18n-teams work}

Becoming a translator is one of the first things people do when starting to
participate in Debian. We need to take this into account, and make these
people's time worth the effort.

One of the problems related to i18n is that this is not a unified task.
There are people who work on debconf screens, people who work with the
debian-installer, people who fix upstream translations, 
people who work on the webpage, etc.

We really need to unify the teams, so that no strength is wasted.

Resurrecting DDTP might be important to achieve this, but there could be
other ways too.  The most relevant point is to think and then implement the
best way of unifying all the Debian translators.

\subsection{Improve the BTS interface}

We've been using the same Bug Tracking System for many many years now, we
might be a bit attached to it, because of the amount of time it's been with
us.  But we need to ackowledge that the BTS needs our attention in order
for us to do a better job at bug tending.

We need a better BTS interface, with many more tags and labels, so that
it's easier to find bugs that a person might be able to contribute to.  For
example, it would be really nice to have a "language" (C, Python, Java,
etc) tag for each package, or an "easy to fix" tag, or a 
"hardware related" tag, or a "tedious to fix", etc.

\subsection{Advertise bugs that need help}

If it were easier to tag bugs that need help (including the language skills
required and the like), it would be possible to make a daily or weekly
short list of the "Current bugs that need your help".

As people start sending patches to these bugs, advertise the names of those
that helped solving most bugs lately.  This could work like ad-honorem
bounties.

In this way, we could incorporate more people into the bug fixing process
give them some special acknowledgement for their work, and finish with better
programs for our users.

\subsection{Encourage team work}

With the birth of Alioth, many teams have been started, and a nice number
of packages are co-maintained and therefore better maintained.

This should be the rule rather than the exception.  All packages should be
in Alioth, and they should all be co-maintained.  

This is also a way of involving more people, that are not really Debian
Developers: they can just have access to contributing in a certain package.

\subsection{NMUs are also teamwork}

Generally, NMUs tend to be seen as an aggression,
when they should be seen as a way of helping each other out.  The only way
that an attitude change towards NMUs can be achieved is realizing that we
are all in the same team, working towards the same goal.

NMUs are teamwork.  We have to keep that in mind, both when we get an NMU
and when we do an NMU.  We are all in this together.

\section{Conclusion}

Many more things can and should be done.  The important part to keep in mind is
that we want to make a better distribution for everyone.  We want it to be good
and usable, and the only way of doing it is by working together and helping
each other achieve the best possible quality.

\end{document}