Hi,
I omit the 'RFC' in the subject as it is not in this state yet but more
something to think about. When starting my thesis I recognized the lack of
responsibilities inside this project and created a list of roles that would be
beneficial to the project. The old version can be seen here[1] and I had a bit
of time to reflect on that.
The list was very specific on some of the roles but not very broad. Right now
we would have more roles than people so the approach of defining and assigning
roles will not work right now.
Then we have some more roles we assume temporarily, but only during the
release process. I think some of these roles should be assumed at all time.
What is the reasoning to not have a continuous process to assign, fix and
verify documentation fixes?
So maybe instead of collecting specific roles I should have started and
grouped it by responsibilities, e.g. something like this:
Responsibilities regarding our users:
- Usable and stable software, predictable releases?
- Working saros-con service at all times?
Responsibilities regarding contributors:
- Handle incoming bug reports in a timely manner?
Responsibilities regarding new developers:
- Documentation to get started and make them feel welcomed?
Responsibilities regarding other developers:
- Review patches, deal with review feedback?
- Do not introduce hard to maintain/fragile code?
In the end we should have something like a 'project manifest' defining how we
want to work, some specific tasks that can be performed by everyone and some
contact points for external people.
Tasks:
Name : Review
Desc.: Review and test each other changes at all times. Respond to review
feedback before opening too many new reviews.
Who. : Everyone dev, all the time.
Name : Handle new and updated bug reports.
Desc.: Try to reproduce new incoming bug reports, try to identify duplicates,
find out if it is broken in the last two releases. Find someone who could fix
it.
Who. : Twice a week on a rotating shift.
Name : Handle documentation issues
Desc.: Handle incoming documentation issues, check if you can get someone to
write internal documentation for the package-info.java files...
Who. : Twice a week on a rotating shift.
E.g. with the two Tasks and Alice, Bob, Carl and Dave a rotation would look
like the one below.
W1: Dave handles bugs, Carl handles documentation
W2: Carl handles bugs, Bob handles documentation
W3: Bob handles bugs, Alice handles documentation
W4:Alice handles bugs, Dave handles documentation.
W5: Dave handles bugs, Carl handles documentation
we could have different task priorities, e.g. with more people we handle more
tasks and if we fallback to only one person we will suspend these tasks.
Someone starting a thesis should enter the rotation and be assigned additional
tasks, someone leaving the project should leave the rotation but also pass on
his tasks to someone else.
comments and ideas on how to proceed?
holger
[1] http://www.saros-project.org/Responsibilities
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Dpp-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dpp-devel
