Not all operations, such as deciding on membership, should be available to all members.

Submitted by Eelco Visser on 4 January 2013 at 11:42

On 4 January 2013 at 12:23 Sander Vermolen commented:

Feel free to change it, but I deliberately designed YellowGrass without system admins. Users in YellowGrass are from the ground up principally equal. They can gain additional privileges (e.g. project member and project owner) by using the system. That makes the system easy to setup, easy to maintain (with no maintenance tasks at all) and makes it open to the rest of the world. I designed it as a self-sustaining system. Clearly it required to rethink a couple of the traditional admin tasks, but I found that all of these could be replaced by other mechanisms. Again, feel free to change it, but just to comment that there is a reason there are no admins in the system.


On 4 January 2013 at 12:39 Eelco Visser commented:

And that can be a good default policy (all members are admins), but for larger projects with more (potential) members I would like to distinguish roles for example in the capability of accepting new members. But also setting the roadmap may not something I want everyone to be able to do.


On 5 January 2013 at 17:03 Eelco Visser commented:

To clarify, I do not mean system admins, but project admins, i.e. distinguishing roles within a project. And deciding about project membership, not application accounts.

Log in to post comments