Welcome to Codidact Meta!
Codidact Meta is the meta-discussion site for the Codidact community network and the Codidact software. Whether you have bug reports or feature requests, support questions or rule discussions that touch the whole network – this is the site for you.
Post History
My main area of concern would be your "Problem", point 2. You seem to have put a lot of thought into that one as well, but I have a number of questions. I'm first most interested in fixing the top ...
Answer
#1: Initial revision
My main area of concern would be your "Problem", point 2. You seem to have put a lot of thought into that one as well, but I have a number of questions. I'm first most interested in fixing the top level groupings. Are the security levels basically just `mods` and `users`? I'm seeing `staff` tags as well. Does that carry any particular organizational, process, or security meaning in this context? And can you think of any other possible "exception" groups (e.g. `guest`)? It looks like you're doing a good job of organizing the "privilege structures". I was going to stop and ask for that before all else - then I scrolled down. So kudos there. However, there are a number of potential layers of abstraction between "privilege" and a high-level classification like `mod`, and it's probably a good idea to flesh out any other similarities between users that might impact or be proxies for their privileges. What about crossover between groups? I.e. can a mod be denied some mod privilege, either temporarily or permanently, but still need to be "a mod" for some reason? Or is a fully trusted user essentially equivalent to a mod in all access within a site? Once a privilege is unlocked, can it be removed again from the frontend? In particular, can adjustments to the qualifications, or "win conditions" cause existing privileges to be added or removed? On a personal level (i.e. as an end user), I didn't really get excited about the idea of the abilities system because it seems potentially ornerous. If it "just works", then in principle it does seem like a rational concept. But realistically, I don't actually want to have to "prove" to anyone that I know how to do things. While I can accept that it's sometimes necessary, it easily becomes monotonous. In that vein, I feel like there's a significant missing component here, which is probably best encapsulated by a concept of "general competence and maturity". I'm a grown-up, and I want to be treated as one. We can't guarantee that's true of everyone coming to that platform, and in fact we must expect it won't be the case for many. But once I feel like I've put in the leg work to prove it, I don't want to be hassled anymore - pretty much at all. The key is that the software be designed to make the same kind of decisions that a human mentor would if they were manually assigning permissions each time. Yes, if I've only ever posted answers, then suddenly go to edit someone's question for the first time, then it's hard to judge my competence or decide the risk. And there probably do need to be some minimal safeguards in place as you move into new tasks on the site. However, the risk is significantly lower if I've posted 50 good answers over a year, with lots of upvotes, than if I just made my account yesterday. That's why SE's reputation/privilege system works at all. So I think there needs to be a concept of a general "user trust level", which unlocks at least some of the more ornerous safeguards after sufficient contributions in *any* area of the site. I also think that the abilities system, while innovative, and interesting to the nerds among us, should really be a hidden "under layer". If end users feel like they have to spend time learning to understand it before jumping in - we've already lost.