Hi all.

This is going to be a rather long mail. It will talk about some problems
the project is currently facing and will inform you about some upcoming
changes. In addition, we hope to get input from you. Read on.

Where are we now?
================

During the last weeks, I talked to people involved in or using Madwifi.
The following problems (among others) were mentioned:

1. Lack of project management
-----------------------------
Since the time we disabled the various trackers that were in place (for
bugs, patches and feature requests) it became hard to keep track of
submitted items and their current status. This seems to be true for the
users, and it is true for the developers.

Some examples:
- Is this new report just a dupe of a problem that already has been
described before, or is it about a new problem?
- What is the current status of an older report? Has the problem been
fixed, or is it still valid? Is anyone working on it right now?
- Has a patch been submitted to CVS already? If not, why not? Has it
been denied (and if so, for what reason), or was it just ignored by the
developers so far?
- and so on.

Depending on the used MUA, it is more or less complicated to gather all
the relevant information. But it is still far too complicated, resulting
in a waste of time.

As a possible result users might feel they are ignored, their input
isn't appreciated at all, or the project appears to be ceased. Chances
are that people will become frustrated and decide to turn away from
using the driver.

Another aspect that belongs to this "area" is that responsibilities are
unclear. People seem to be unsure about who to talk to, and developers
don't know if they should act on reports or if someone else is going to
do that soon.

2. Lack of documentation
------------------------
During the last months we managed to gather a lot of useful information
in our wiki. Man pages are on their way, and the users guide that is
contained in the preview snapshots for the upcoming code is a great
help. Nevertheless, there is still a lot to do in this field.

But when we take a look at the documentation for developers, things are
really bad. The only documentation for people who want to start
contributing to the source are the comments in the source and the source
itself. Which makes 0.0 documentation for the closed source HAL.

This leads to a bad experience for many newbies, no matter if they are
users or developers, and results in very bad grades in terms of usability.

3. Lack of transparency
-----------------------
It seems to be hard for people not belonging to the "core team" to judge
what is currently happening in the project. What direction does it take,
what is currently worked on, is there any development at all, and so on.

This is a result of the fact that many decisions have been made behind
closed doors in the past, which is bad.

4. Lack of developers
---------------------
A combination of 2 and 3 leads us here: we have few active developers.
Those who are currently working on Madwifi work for companies that make
use of the driver and like to contribute back to the community. While
this is very nice, this also means their contribution is usually very
unsteady (depending on the time they can afford for their work).

In addition, two of the current developers either are already or soon
will be out of reach for a longer time.

5. Lack of development
----------------------
That's a virtual lack, since there actually IS a lot of stuff going on
currently. But:

- due to the lack of transparency it's hard for users to find out what
is going on

- due to the "phenomenon" described in 4 (varying intensity of
contributions from active developers) there are phases where not much
code is committed to the CVS

- right now, development in the public CVS repository is suspended in
favour of the upcoming code contribution coming from Atheros; due to
bugs found in the testing code, its release has to be delayed, which in
return adds to the felt "lack of development".

All these issues (along with others that I didn't mention here) add up
to each other. That's bad on the one hand, since it might lead to a bad
reputation. On the other hand, addressing one of these issues more or
less automatically helps to address the rest.

So, what to do about it?
=======================
Some months back there was the idea (originally initiated by Sam, I
think) to move the CVS away from sf.net. The reason was that at this
time sf.net had some problems with their servers.

Out of this idea, and in response to the problems the project is
currently facing, the following plan has evolved:

1. We will switch from CVS to Subversion. Subversion has proofed to be
superior to CVS, and it offers some nice features. One of them is the
ability to natively handling binary objects, which helps us getting rid
of the uudecode/sharutils dependancy for systems that are to be used for
building Madwifi.

2. We will start to use Trac (see: http://www.edgewall.com/trac/ ) for a
better project management. Trac offers web access to the Subversion
repository, it provides a powerful Wiki engine, offers a facility to
track bugs, patches and feature requests and has some other very nice
features. All these components are closely tied together, so that
refering from the Wiki to a report in the tracker, for example, is very
easy.

The wiki will be used for all web content. That is the content visible
at http://madwifi.sf.net, as well as the stuff that is in the
documentation wiki.

The trackers will be used to get rid of the "chaos" described above. In
other words: the trackers will be the place to file bug reports and
submit patches.

Trac offers management of "milestones", to which tickets can be
attached. A milestone is not reached until the attached tickets are
marked as solved.
This facility along with the "timeline" (a list of events that happened
in the past) should help to make it clear where the project is going to.

3. We will offer a cross reference for Madwifi, which will be based on
the most current development code. It will be created by making use of
lxr (see: http://lxr.linux.no/ ). This is no replacement of any means
for developer documentation, but a first step to provide better support
for people trying to contribute to Madwifi.

As a side effect to the mentioned decisions, this means we have to move
all these services away from sf.net (Sourceforge doesn't provide svn
repository hosting, and it's unclear when (if at all) this will be
available). Other services, such as the mailing lists or (later) the
distribution of released code, should remain at sf.net for now.

These services will be available under the madwifi.org domain, which has
been contributed to the project by Avlin Olga. The server that hosts
this domain and the Trac stuff is the same that currently offers the CVS
archive. Traffic will be sponsored by my employer, which runs the NOC
that server is located in.

Current status of the move is:
- Subversion repository up and running (currently for testing purposes
only, not for actual development); it has been converted from the
current CVS repository, and contains the complete revision history of
that CVS repos; it will be reset to a sane state as soon as the new site
is officially launched.

- Trac installed, configured and running; the wiki needs to be filled
with content.

- lxr up and running, the cross reference is automatically updated on
every commit to the subversion repository.

- generation of tarballs will be coupled the same way, so that a new
tarball is generated on every commit to the corresponding branch.

What else will be done?
======================
This is where the community finally comes into the game (again). Now is
the time to speak up. What problems do you see, what ideas do you have
in mind, what should be done?

If you have additional ideas for the project's new website, tell us
about it.

You want to help with documentation? Or with porting content to the new
Trac wiki? You're welcome to do so, please speak up as well and we'll
get it done.

Start to discuss about what direction you would like Madwifi see going to.

Things like that, you get the idea.

Bye, Mike

PS: Eventually answers from me take until monday, I'm currently "on tour".
-- 
Sign EDRI petition against data retention:
http://www.dataretentionisnosolution.com
Use PGP/GPG!
My key: http://keys.indymedia.org/cgi-bin/lookup?op=get&search=62C29B94
Fingerprint: BC2E 79BF 0C8F 0282 864B 9CEC 8343 5169 62C2 9B94

-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl