If role-gating is the way DAO contributors are accumulating local reputation and access to their Discord server, why wouldn’t that be the way it’s structured in their work management tooling as well?

Enter - Dework Role Gating

In Dework it’s possible to granularly define which roles that grant you certain work access. Work is broken down into Projects and Tasks. You can very granularly control who should get access to what work by using Roles.

A key to using Roles is to make them granular and ranked.

Granular: A role should be precise enough to accurately describe the specific skill in question. ‘Product’ for instance would be too broad - it is better to have ‘design’, ‘product manager’ or ‘frontend dev’.

Tying back into the problems we touched on initially, and how it changes using Role gating:

1. It’s hard to have both bottoms-up autonomous workflows AND **to get 
   people to consistently work on useful stuff rather than what they feel like**
  *--> Contributors are able to choose among relevant projects and bounties and 
  grab and execute them autonomously.* 

2. It’s hard to know who’s the right person for the job
  * --> Granular roles make this easy! *

3. Dealing with onboarding & applications from outside contributors can be a mess
  *--> Only for first-time contributors do you need to deal with applications.
   Otherwise, you just gate to the appropriate level of competency & trust that 
   the specific unit of work requires.* 

We’re not claiming that this approach will remove all headaches when it comes to working with contributors, but it’s a clear improvement on the status quo. After all, there is no ‘Lean Startup’ doctrine of best practices yet for DAOs working with contributors - hopefully, this guide can serve as a chapter in that book when it’s finally written.

If role-gating is the way DAO contributors are accumulating local reputation and access to their Discord server, why wouldn’t that be the way it’s structured in their work management tooling as well?

Enter - Dework Role Gating

In Dework it’s possible to granularly define which roles that grant you certain work access. Work is broken down into Projects and Tasks. You can very granularly control who should get access to what work by using Roles.

A key to using Roles is to make them granular and ranked.

Granular: A role should be precise enough to accurately describe the specific skill in question. ‘Product’ for instance would be too broad - it is better to have ‘design’, ‘product manager’ or ‘frontend dev’.

Tying back into the problems we touched on initially, and how it changes using Role gating:

1. It’s hard to have both bottoms-up autonomous workflows AND **to get 
   people to consistently work on useful stuff rather than what they feel like**
  *--> Contributors are able to choose among relevant projects and bounties and 
  grab and execute them autonomously.* 

2. It’s hard to know who’s the right person for the job
  * --> Granular roles make this easy! *

3. Dealing with onboarding & applications from outside contributors can be a mess
  *--> Only for first-time contributors do you need to deal with applications.
   Otherwise, you just gate to the appropriate level of competency & trust that 
   the specific unit of work requires.* 

We’re not claiming that this approach will remove all headaches when it comes to working with contributors, but it’s a clear improvement on the status quo. After all, there is no ‘Lean Startup’ doctrine of best practices yet for DAOs working with contributors - hopefully, this guide can serve as a chapter in that book when it’s finally written.

If role-gating is the way DAO contributors are accumulating local reputation and access to their Discord server, why wouldn’t that be the way it’s structured in their work management tooling as well?

Enter - Dework Role Gating

In Dework it’s possible to granularly define which roles that grant you certain work access. Work is broken down into Projects and Tasks. You can very granularly control who should get access to what work by using Roles.

A key to using Roles is to make them granular and ranked.

Granular: A role should be precise enough to accurately describe the specific skill in question. ‘Product’ for instance would be too broad - it is better to have ‘design’, ‘product manager’ or ‘frontend dev’.

Tying back into the problems we touched on initially, and how it changes using Role gating:

1. It’s hard to have both bottoms-up autonomous workflows AND **to get 
   people to consistently work on useful stuff rather than what they feel like**
  *--> Contributors are able to choose among relevant projects and bounties and 
  grab and execute them autonomously.* 

2. It’s hard to know who’s the right person for the job
  * --> Granular roles make this easy! *

3. Dealing with onboarding & applications from outside contributors can be a mess
  *--> Only for first-time contributors do you need to deal with applications.
   Otherwise, you just gate to the appropriate level of competency & trust that 
   the specific unit of work requires.* 

We’re not claiming that this approach will remove all headaches when it comes to working with contributors, but it’s a clear improvement on the status quo. After all, there is no ‘Lean Startup’ doctrine of best practices yet for DAOs working with contributors - hopefully, this guide can serve as a chapter in that book when it’s finally written.