Well, judging by this chart, devs are most active when they are first added to the team (end of march), but quickly become much less active. Some might suggest that just keep adding more and more devs to the team, but this is a simplistic answer to a complex problem, and would be very inefficient. Instead, I would like to propose a rotating schedule: the dev team would be broken into four sub-teams, and each sub-team would be assigned a season. Each sub-team would only be allowed access to the SVN during their corresponding season, and in this way we will keep the devs from becoming too worn out to continue, and keep SVN activity at a max (because, you know, thats the best way to gauge how much the devs are actually working).
AssaultCube - Forum
›
AssaultCube
›
General
next release (formerly "1105", but that's just incorrect)
next release (formerly "1105", but that's just incorrect)
|
next release (formerly "1105", but that's just incorrect)
|
 Well, judging by this chart, devs are most active when they are first added to the team (end of march), but quickly become much less active. Some might suggest that just keep adding more and more devs to the team, but this is a simplistic answer to a complex problem, and would be very inefficient. Instead, I would like to propose a rotating schedule: the dev team would be broken into four sub-teams, and each sub-team would be assigned a season. Each sub-team would only be allowed access to the SVN during their corresponding season, and in this way we will keep the devs from becoming too worn out to continue, and keep SVN activity at a max (because, you know, thats the best way to gauge how much the devs are actually working). |
|
« Next Oldest | Next Newest »
|