Hi Holger, see inline.
Am 10.07.2012 20:28, schrieb Holger Freyther: > 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? As long I was a member of the team, the predictable release was mainly the last week of every month. But sometimes for no good reason. New features were added that had sometimes not tested very well. Bugs were fixed without any real priority. There was no real milestone plan, saying xyz must be fixed for release abc. It is up to the project to take the agile approach and ship new releases in a very short amount time ( less than one week) or develope until a concrete milestone has been reached. > - Working saros-con service at all times? > > > Responsibilities regarding contributors: > - Handle incoming bug reports in a timely manner? > I think this should be part of the project lead, as this is the most experienced person in the team who can understood some issues much better than the rest of the team. At least he / she must assign the prio. for this bug and should assign it to a team member that can handle the bug very well. > 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? > I think feedback should be given as fast as possible. Doing code review only on day x between y and z o' clock can be very frustrating. A submitter should not ask / bid other team to do a review (I do not mean the Gerrit option btw, it is ok to put some members to that list, because they may have deeper knowledge regarding the changes in that patch). From my personal experience ... we had some members that always ignored the fact, that we had a review board or only replied if a patch was less than 5 lines long. > 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. > See above, definitely the right way. > 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. > I think the project lead should assign such tasks, at least if there are no volunteers :P > 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. > This is a really hard task for new members. No documentation is better than bad documentation. > > 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 > Regards, Stefan ------------------------------------------------------------------------------ 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 Dpp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dpp-devel
