Previous Entry Share Next Entry
Do these sound like the right "standard" roles?
querki
jducoeur wrote in querki_project
On the to-do list in the not-too-distant future is a task that I think of as "Make Security Management Not Suck".

The thing is, Querki's security model is *very* powerful, and massively customizeable: I've been putting in place a lot of fairly fine-grained permissions, and the list is growing quickly. Each of those permissions can be applied at the Space, Model and Thing level. In the long run, if we go as far as I'd ideally like to (adding programmable permissions), we may wind up with the most powerful security model I've ever come across. For power users, it's pretty excellent.

But for everybody else, it's horrible.

I'm pretty sure that at *least* 99% of users are never going to care about all that flexibility, and that it will just annoy them. Indeed, even for power users -- heck, even for me -- I expect that they won't care about all that for most of their Spaces. What folks want is a *very* short list of sensible options to choose from.

So here's my first-draft guess of what the standard "roles" should be. These are basically the buckets that Members go into, and will be the "standard" way of thinking about security. You'll be able to tweak the definitions of these (and/or define your own Roles/Groups), but I'd like to have the defaults be correct enough that people usually don't need to.
  • Commentator: can read Things, leave Comments and give Ratings, Reviews and any other User Values that are defined for this Space.

  • Contributor: can do everything a Commentator can do, plus create and edit Instances. Can moderate contributions from Commentators and the Public, if those are allowed in this Space. (Moderation should be opt-in, but Contributors are offered the opportunity to do so.)

  • Manager: can do everything a Contributor can do, plus design Models, manage most Permissions, edit the Space itself, issue invitations and accept join requests. Managers are essentially Admins, and can take *most* actions.

  • Owner: can do absolutely everything. There is exactly one Owner at any given time, and it is defined as the entity paying the bills. Only the Owner can assign people as Managers, delete or give the Space to someone else.
I'm deliberately avoiding the Google Docs concept of "co-Owners", to avoid ambiguity: in the final analysis, *somebody* has the ultimate say, and that should be whoever is ultimately responsible for this Space. But the intent is that Managers are *almost* Owner-level, with a very high level of trust.

The feature I am most on the fence about is Model design: I'm honestly uncertain whether it belongs in Manager or Contributor. I'm also on the fence about whether Moderation belongs in Manager or Contributor. I've considered adding a middle "Editor" layer to reflect that, but I'd prefer to keep this list as short as possible, so I'm seeing whether it works without that.

Opinions? Does this seem like the right list? Am I off-base in where I'm assigning features? Would it make more sense with an "Editor" level between Contributor and Manager, with Moderation and Model Editing rights? Do the names make sense? Changing these roles once they are in the wild is going to be dangerous, so I'd like to get it more or less correct out of the gate...

  • 1
Since I still haven't had a chance to try using it, I may be way off base, but I think I lean toward a "designer" role in between Contributor and Manager. Moderation could either be reserved for a separate level of Editor, or included in the Designer's role, with exact use of powers depending on the structure of a particular Owner's team.

Speaking of Owners, one thing that has annoyed the heck out of me in a lot of systems is the lack of understanding of corporate owners -- if I set up a social network for my company, the _company_ is the owner, and I am only a manager, and it is irritating -- and in some ways dangerous -- for me to be listed as owner. Perhaps you've already considered this issue; if not, I urge you to do so.

That's part of my thinking in the Owner/Manager split -- I expect this to happen fairly often. The differences between Owner and Manager should be few, and pertain to situations where ultimate authority is required. Other than that, Managers should be able to do anything Owner can do, so that the Owner can effectively delegate day-to-day running of the Space to one or more Managers...

Looks reasonable to me. Moderation at the Contributor level both works for my use-case (see below) and makes sense to me as a default, so long as there are alternatives for a Space where that's not appropriate. (Perhaps: make it easy for a Manager to turn off the "has option to moderate" flag for a Contributor.)

In the use-cases I forsee for my playtesting Space:
* I'd be a Manager;
* The publishers would be Contributors;
* The playtesters would be Commentators.

Are contributors going to be limited to editing their own Instances? I think the default would be no, to be in line with the Wiki notions of communal contribution and edit. But that should be an easy flag to change for a lot of business purposes.

Correct. In fact, we don't yet have the necessary internals to limit Contributors to only editing their own stuff, although that will come in due course.

I agree that it's important for business, but business is really a secondary consideration at this point -- I'm mostly focused on the consumer product for now, and I believe that most consumer situations are more all-or-nothing...

  • 1
?

Log in

No account? Create an account