As the title states, what would it look like to codify operational behaviors?
–
What parts of Public Assembly ¶ struggle from lack of process? And the inverse, what parts of PA are actually more valuable because of lack of process?
A code of conduct and a formal (and cohesive) standard of what parts are “open source”, how things like headlessness seeds into daily decision making, and how to talk to people outside of the scope of your teams sprint, an exhaustive list of resources etc would be nice,
Also I’ve said this before but open to view doesn’t necessarily mean it was sourced from an open pool of contributors.
As for coordination, the only thing I’m aware of is that some people work in the forum, some work in a slack, some work in person together, get on calls…but is every call publicized, no.
A big barrier for me specifically is you can be seen as aggressive if you are serious about maintaing a strong follow up culture to accommodate the async nature of this org. If you are extremely direct about what exactly you need at a given time, there is sometimes no guarantees or answers so I try to only go off what is public or onchain.
You find out at the same time everyone else finds out if an idea has been put on backlog, and you can be doing the exact same task as someone else or completely removed from the sphere and have your work go in vain.
There’s constant gaps in information as long as comms and operations aren’t prioritized but I also feel like if there was more content outputed at different frequencies right now it would make it more entropic because that layer of communication still has a need for curation.
I think our process documentation was easier to follow in september - november using Notion for the micro/metablogging, There’s also no voice feature on this platform.
The upside to this freedom is more room for innovation.
need some more time to think about this question before responding thoroughly. in the meantime, made a graphic that I think helps add more structure to this question. what we’re seeing is that PA really can expand in so many directions – and its up to everyone to figure out what directions are important and where to allocate resources accordingly. welcome edits to this graphic (time is an unmarked X axis here)
i think an interesting thing to call out, is that while all of these efforts can/should/need to be happening simultaneously/in parallel, the resource allocation (+ execution quality – cannot forget about execution quality) in each direction will affect the internal/external perception of PA differently, resulting in some form of the graphic below
1 Like
I think there’s a critical differencee between “open” (anyone can do anything) and “inviting/accessible” (how easy it is for anyone to do anything). making sure things are open is an essential first step that shouldnt be undervalued.
that being said – prioritizing how to make things accessible should coincide with efforts in making things open bc I think its easier to do that from the beginning than retroactively – and thats where we can do better. resource allocation resource allocation resource allocation
Maybe it would be worthwhile to define more concretely what these individual lanes correspond to. And then perhaps we address how resources are currently being allocated towards each lane.
It might highlight some gaps that although may be apparent to us, are harder to see from someone looking in.
So what does a code of conduct look like, and to what ends does it extend?
I could see things like this being helpful.
- How to create a forum post capable of mobilizing contributors
- How to create an effective onchain proposal
- Where to discover what the DAO is currently engaged in
Just throwing ideas out there.
Saw this on twitter a few days ago. Some kind of mechanism like this could be helpful to build down the line.
2 Likes
i agree w/ @valcoholics that some sort of agreed upon standard of procedures is paramount.
New/Present members require a “north star” in order to properly adopt, participate in, and contribute to the PA workflow and mindset.
This could look like:
-
examining current workflows and establishing a solid ‘jump point’ standard, formalizing this, then disclosing
- setting a cadence to: (How often this occurs + A formal defining of) what updating PA workflow processes looks like
-
establishing what priorities should be upheld when producing as a WG, a full collaborative effort that formalizes the ideas Val introduced here
-
(this is kinda getting at what this post is trying to gather but flow w me here) A clear definition/separation of what is considered Strategic operations[contextual estimates/predictions for projects/efforts that intend to benefit the PA-eco, etc]
- what is considered Tactical operations[disclosures of schedules of projects/PA endeavors, if the market Do-Kwon’s how does PA respond, etc]
-
disclosure of what Quality Control processes look like for PA_WGs?
-
i agree with @salief that @0xTranqui’s graphic would benefit from a fully visualized progression. Otherwise for me the P graphic just illustrates that PA is entropic, but then what?
- also agree that the resources that help PA be what it is should be spotlighted
-
settling on how granular ‘public’ is meant to be interpreted.
- just open repos? Frequency of Announcements & what all is disclosed there, etc
This was a thought flow pls correct me where applicable😳
The EIP process may be a good example example of the type of open and accessible process being discussed here. It is not exactly inviting but it is well-defined and easy to engage with.
https://eips.ethereum.org/EIPS/eip-1
It may seem counterintuitive, but some amount of structure actually increases freedom by isolating coordination. When there is a lack of structure you end up with coordination points all over the place and nobody gets anywhere. When there is too much structure, you get a similar problem.
One place where I think more structure would be beneficial is in the process of WG formation. The goal of this process would be to identify an accepted path to WG formation and define the relationship between each WG and PA. IMO, this would make WG formation super inviting.
3 Likes
Perhaps we could focus specifically on codifying process around working group formation as a kind of experiment that might lead to more insight when developing procedures for other types of coordination.
Is that too much of a jump? Do we need process for how working groups operate before process surrounding working group formation?
1 Like
I think codifying processes is secondary to figuring out 1) what do we want to do 2) what working groups would be helpful to coordinate contributions on those things
each working group should be codifying its own processes?
for example, I imagine a group focused on protocol development may function very differently than a group focused on design or onboarding
more structure is clearly needed, but imo needs to be implemented as minimally as possible or else issues with friction caused by bureaucracy will immediately pop up
1 Like