[PLUG-Devel] "managing" open source projects

[der.hans]

Am 05. Sep, 2006 schwätzte Josh Coffman so:

>  quick background:
>  I'm a windows developer who loves linux and open
> source products. I also happen to be part of team
> growing towards Agile development methodologies. Not
> all Agile/XP  would apply well to us partly because we
> are a virtual office company. I was thinking about
> this when it occured to me that the way OSS projects
> are handled might
>
>  the question:
>  Anyone know how large OSS project work on a
> day-2-day and dev cylcle basis? In particular, the
> kernel team.. don't they mostly use email and IM to
> coordinate? And how do they appoint tasks?

Josh,

I haven't really worked on large OSS projects. I have participated some
via mailing lists, etc.

For $dayjob I work in a semi-virtual environment. Some of the team
lives elsewhere, heck even those of us in town work in two different
offices. Some of us don't do the morning thing very well. As a result we
end up with geographical and daytime seperation.

We end up doing a lot of email, IRC, and IM for communication. We do some
telephone conferencing and occasional web conferencing.

We also do a lot of documentation on the group wiki.

For task assignment and follow up it goes via the same communication
mechanisms as the other communication.

At one point we were maintaining a project spreadsheet, a project
presentation, a web-based timesheet and a wiki.

At another point we reported to two managers and 4 project managers. It
was joyous.

Our team is pretty self-sufficient, so task assignment and follow up has
been pretty easy. We even have people who update documentation without
having to wring it out of them.

The keys, in likely order of importance, have been 1) self-sufficient
workers; 2) email/IRC/IM; 3) wiki and good docs; 4) telephone conferences;
5) web conferences.

2, 4, and 5 probably depends on the mix of people as to what's important.

For instance, my customers are very heavy with 4 and 5 and mostly just use
2 to setup 4 and 5 or arrange for where to eat lunch.

Important tools:

. some sort of documentation engine
 	- wiki works well for small teams, if people will use it
 	- add RSS feeds for updates to make it easier to get notified
about changes
. request tracking mechanism
 	- can also be used for bugs
 	- needs to be easy to use
 	- email interface for most tasks adds to ease of use
 	- web interface improves big picture view and some people hate
email
. group building
 	- give people a chance to give non-work updates at the beginning
of meetings
 		+ at a regular Monday afternoon meeting for another group
the PM asks what everyone did for the weekend. 15 people and we're usually
done in less than 5 min. Gives time for latecomers to show up and gives a
chance for personalities to come out as people make comments/jokes
 	- have a food meeting: have food brought in for groups in the same
office and sent to homes of those working out of their house
 	- have a state of the whatever meeting once in a while to let
non-associated subgroups see what everybody's doing

ciao,

der.hans
-- 
#  https://www.LuftHans.com/        http://www.CiscoLearning.org/
#  Join the League of Professional System Administrators! https://LOPSA.org/
#  "If I want my children to work hard, I better be the hardest working
#  person they've ever met. If I want the children to be nice, I better
#  be the kindest human being they've ever met." -- Rafe Esquith