This is great. There is a UX DAO that applies a variation of the idea.
When a project in announced, there is an assigned Expert, and members can apply to work in that project according to some specified tasks:
@ddadybayo.eth shared that DAO in the mod chatā¦ think this is what youāre referring too @Erik_Knobl - Introduction - Skill Attestation Protocol
This stuff is so exciting!!
I would also add as flagship project (I think I havenāt read it anywhere):
A self-made course platform. It would be cool to build a decentralized web platform where experts and then everyone from the DAO can add courses and be rewarded for it.
It could also be a nice way to be known among developers and to start earning as a DAO.
My guess, processes, as a bear minimum need to be documented. ( key words: governance, transparency, consistency, efficiency, FAQ, how to, contributorās guide, etc.) Donāt think that function can be fulfilled by commented code.
Apart from that, more generally, builders need documentation.
Around:
We really need to have the conversation with seedclub to understand what the scope of that engagement is - assuming we pursue it and get it.
Iāve been thinking about something similar, except in my mind instead of a core engineering team we have a core open source team. The idea to me is that if we train a group of people in filling various open source roles (like maintainers, triage, documentation writers, etc.), we have a group of people that can start/join a project and begin to inject stability, clarity, healthy patterns, ecosystem thinking, etc.
In some ways this might just be semantic squabbling between ācore engineeringā and āopen sourceā (and maybe thereās even a need for both!), but I think open source organizations tend to be much closer to āgardenersā than your typical core engineering groups. Theyāre less about establishing concrete architecture patterns and such (though open source orgs do do that) and more about thinking about and implementing the meta infrastructure around a project that allows it to succeed:
Some of these things will be the same for each project and some of them will be different. Having an open source org that can educate contributors allows us to provide projects with people that can help think through these various concerns in order to set up processes/automation/teams that meet the unique needs of each project.
You hit the nail right on the head here @with-heart and that was kinda my vision for the proposal too. I think though, at least in my head, both the āengineeringā and āopen sourceā teams are one and the same. We could start out as one unit and then perhaps split out into smaller units/squads after people get a feel of what they like and/or want to learn
Naming teams could be important in the future because it makes people more flexible in their thinking.
A content team might think about producing content and an event team might think aboutā¦ well ā¦doing events, but a public awareness team might do anything that helps to improve public awareness.
I know, naming things is hard, but if we named the teams by their goals and not by their skills, this could make them more flexible, more creative, and more open.
Another option is to have flexible/amorphous teams. People should be able to join and leave teams as they find interesting work. In my mind this would at least require a way to broadcast upcoming work for teams through the DAO (the Discord is not it), a way for teams to receive and allocate work, and a way to quickly onboard squads within a team to the work and any team culture/tooling/techniques.
Rapid onboarding might need to be the highest priority in this case, but can serve as a great blueprint for other DAOs.
While I agree that the majority of the DAO can come and go, we should have team leadership (or whatever term is agreed upon) that remains with an overall tasking for longer. They will be responsible for the correct deconstruction of a goal into atomic tasks that can then be accomplished by short-term contributors that are slaloming between whatever groups have tasks in need of the individualās skills.
IMO it would be better to avoid as much hierarchical organization as possible. Instead, teams can have project managers or even just project proposers that offer up projects (need it more quickly? offer more money/tokens) and squads (amorphous groups - like a hackathon group - that come together to work on some project) can claim them. RaidGuild has a familiar process with parts that are certainly adaptable to what weāre doing.
correct deconstruction of a goal into atomic tasks
Itās a rare case that there is just one ācorrectā deconstruction of some goal or project. Itās worth a discussion over how the DAO should do work allocation and how to enforce that methodology, but squads who pick up a project should be expected to break it down as needed.
I think itās worth having a look at the Valve Handbook.
Valve is famously known for a very flat hierarchy and autonomous groups. Now, while I have never worked at Valve or know anyone who did to confirm how well it works for them, I do still think that the ideas in the handbook resemble to a great extend our values and also the way we try to organize ourselves.
An excerpt from the handbook :
But how do I decide which things to work on?
Deciding what to work on can be the hardest part of your
job at Valve. This is because, as youāve found out by now,
you were not hired to fill a specific job description. You
were hired to constantly be looking around for the most
valuable work you could be doing. At the end of a project,
you may end up well outside what you thought was your
core area of expertise.Thereās no rule book for choosing a project or task at
Valve. But itās useful to answer questions like these:ā¢ Of all the projects currently under way, whatās the
most valuable thing I can be working on?
ā¢ Which project will have the highest direct impact
on our customers? How much will the work I ship
benefit them?
ā¢ Is Valve not doing something that it should be doing?
ā¢ Whatās interesting? Whatās rewarding? What leverages
my individual strengths the most?
A link to the handbook: https://cdn.cloudflare.steamstatic.com/apps/valve/Valve_NewEmployeeHandbook.pdf
A link to the audio version 
for the commute: https://podcast.nfx.com/episodes/valves-new-employee-handbook
As a beginner I really love the idea of this. I desperately want to contribute and help others learn someday.
Late, but I just wanna say this could be a really excellent idea for a flagship project for the dao
åøęęäøŗäøęē¤¾åŗåæęæč ļ¼ä½ęÆč±čÆäø儽ļ¼åŖč½åäøäŗē®åå·„ä½
