[isf-wifidog] Roadmap and Project Manager
max.horvath at maxspot.de
Mar 3 Jan 11:19:29 EST 2006
>>> in the last few weeks we've all been discussing about the things
>>> WiFiDog lacks about.
>>> One thing I'm sure we currently miss the most is an active project
>>> manager and of course one of his most important responsibilities to
>>> create: a roadmap.
>> Unlike others, I had no vacation this Christmas while everyone
>> else suddently
>> seemed to have heaps of time to work on wifidog. I even excused
>> before christmas. Bashing me publically is not really the best
>> way to start
>> an intelligent conversation about it.
> Hey Ben. I'm pretty sure that no one is bashing you. Expescially not
> Max. But Max, if you are we'll have to spend the last bit of our
> money to buy Benoit a ticket to germany to drop kick you in the pants
Wohoo ... I don't know why ... but Benoit ... you got hold of the
wrong end of the stick! This wasn't meant as personal offense ...
it's just that something has to be changed ... that's why I've been
writing it to the group ... not as a offence to you.
But Michael - maybe it's a good idea to spend the last bit of your
money to buy Benoit a ticket to Germany ... not to kick me in the
pants ... but to drink a few beers ;) ...
> And whether or not someone else could help as project manager, i agree
> the the first steps would be 1) to start up a wifidog irc channel and
> 2) start working on the new wifidog wiki and creating some better
> general documentation. Depending on what happens with that then we
> can talk about how to improve things from there.
Yeah, a #wifidog channel on freenode would be a great idea!
The new wiki would be nice, too. Especially, if it's separated from
ISF. I also think, that a lot of people don't contribute to the
project, because WiFiDog and ISF seem to be a little bit to close ...
Not that I personally think so about it ... but I can imagine many
people do ...
>>> Just an example of my situation as a developer. I have a lot of
>>> WiFiDog could need as improvements. Sure we have a bug and
>>> feature list.
>>> But what we really need is a roadmap so developers among us could
>>> concentrate on specific things to work on step by step.
>> As was mentionned before (several times) the roadmap is obtained
>> by searching
>> the bugs and RFEs by group:
>> -For 1.0
>> -Post 1.0
>> -Long term
>> This would be done automatically if we had a more decent
>> developper support
>> platform. Considering the fact that we are apparently going to go
>> trough a
>> third wiki transition anyway, and that we are having problems with
>> sourceforge's CVS, I think we should take this opportunity to move
>> to SVN and
>> an integrated wiki and task manager like Trac.
Good! On which server would we be working on?
>>> So - any input and/or ideas?
>> -I think the lack of a unified design document hurts us much more
>> than the
>> fact that the roadmap is hard to use. Unfortunately, I am not
>> even sure the
>> few design-like documents I posted to the mailing list over the
>> years after
>> reaching a consensus after hours of arguing on mailing lists or in
>> were even carefully read by most people. It takes hours to agree on
>> relatively simple but important things such as the Smarty
>> integration level
>> desired. This is somewhat normal, but getting a consensus on a
>> full design
>> document that people will actually honor and respect would be
>> weeks of pretty
>> much fulltime work for the coordinator. I don't think anyone has
>> that kind
>> of time to commit to just writing.
Sorry, but it's kinda hard to find those documents, because the
mailing list is not searchable. I also think that documents like that
belong to other places but a ,ailing list ;) ...
>> Right now (well, up till a month ago), I spent hours every week on
>> related things, almost 100% of it being invisible project
>> management of some
>> sort. No time left for coding and actual work, this is just no fun.
>> Unfortunately, every organisational change I proposed to implement
>> simple OSS
>> best practices and make international developement easier have
>> meet moderate
>> to heavy resistance locally. To put it bluntly, there is little
>> point in
>> doing project management if people won't either do what the
>> manager proposes
>> or come up with and defend an alternative. I am emotionally tired
>> of it, and
>> I don't intend to attempt it again untill people seem to be more
>> open to it.
>> It may just be that the project doesn't want or need a singular
>> manager (I certainly don't think it's workable at this stage). At
>> least a
>> lot of people seem to independently recognise the need for change.
Sad to hear about those problems :( ...
Maybe all international (or non-local) developers should come to
Montreal to help you managing your guys (just kidding) :D ...
>> But here are a few communication related things that are easy and
>> that I think
>> should be priorities to help the project in the short term:
>> -I've been very liberal with commit access to lower the barrier of
>> However, if you want to commit a change that isn't a bugfix or simple
>> improvement, it is probably best to check on the mailing list if
>> it has been
>> discussed before.
>> -Someone should make sure that the doxygen documentation for the
>> auth server
>> actually builds, and should create a nightly corntab entry to
>> build it from
>> CVS and put it up on the web. There is a ton of design-related
>> in there.
Well, PhpDocumentor very compiles fine for now and I think that we
should stick to it, because it also let's you add end-user and
tutorial-like documentation to the auto-generated documentation. And
it also runs on shell - so a nightly build is no problem at all ...
>> -Use the IRC channel (#ilesansfil on freenode, or we can create a
>> one if it makes anyone feel better). We used it exensively when
>> we coded the
>> gateway, and it helped smooth out cummunication massively. We are
>> the only
>> OSS project of significance I ever heard of that actively resists
>> this idea.
>> Hopefully I don't have to explain why this is almost essential.
>> -It may be more on a psychological thing, but I think wifidog
>> should have it's
>> own wiki. People are just too shy to ask for permissions on the
>> ISF one.
>> -We need a better and really simple task and milestone manager
>> like Trac (I
>> don't really care which one we pick, but we should pick one).
Please - yes! But again - which server? Is yours (ISF) fine or do we
need another machine?
>> -Now that max has proposed coding standards, and no one opposed,
>> we shold
>> respect it.
Absolutely ;) ...
>> -We should make the mailing list archives searchable.
That one, too!
So long, Max!
More information about the WiFiDog