Absolutely. I think we will probably have to establish a process by which people can ask for something to be added to the next meeting agenda for each WG stewards meeting; for example, Ethereum Cat Herders do this via a GitHub issue for each meeting.
3 Likes
In favor.
This is similar to how the Community Working Group has intended to handle requests for subgroups, but with more depth and DAO-wide visibility. It gives contributors responsibility over of an idea and pushes it towards execution.
A simple, off-the-shelf RFP outline would likely meet our needs with minimum tailoring.
The discord/discourse stack is not providing the coordination tools to get off the ground.
For this RFP model to successfully scale, we will need to implement project management layer. Right now, there’s no clear way to coordinate cross-working groups or even see what projects are currently underway. This, in part, lends to good ideas stalling while in the ideation phase.
@nick.eth’s mention of Github in response to @daylon.eth could be lightweight solution by using issues and project boards.
@vegayp is already looking at using Github for the Community WG and I was going to mock up a DAO dashboard on a Notion account tomorrow. It’s a start. We’ll need to pick something we all can use. I’ll tap into the other WG’s and see if there is a preference.
9 Likes
I also think that we would need something to visualize these processes, a kind of kanban-style board.
2 Likes
This. Plus, a dashboard could be really useful. Perhaps the first RFPPs could be to a) hack Discourse build to include some custom features, and b) create a dashboard.
I can see how GitHub came to your mind as a place to coordinate even if it requires some work onboarding new users.
2 Likes
Perhaps we can put out an RFP for someone to implement and maintain DAO project management. 
As a lightweight option, GitHub issues and project boards do work well; project boards are particularly good at getting an instant insight into the status of things.
4 Likes
How about forking GitLab and building our own (simpler UI-friendly) Git + Project Manager with additional features that you like? We could put it alongside Discourse build on the same server and probably also test crosstalk between Git and Discourse build. We use a custom build of GitLab at my web2 work, although it hasn’t been customised as much as it could be since we do not really need it (coordination is minimal in our workstreams, most people work standalone or within exclusive small clusters with minimal crosstalk). Cherry on the cake could be to make SIWE the standard Identity Provider across all custom builds of ENS DAO. This is a serious RFPP that I am kinda-sorta proposing here 
I would really rather not get distracted with building our own tooling except where absolutely necessary. There are definitely existing project-management tools we could use.
4 Likes
My A Dynamic Task Reward System for Workgroups idea was intended to solve this exact problem and does so more efficiently both from a cost-perspective and a speed of work-perspective.
It could be combined with an upper and lower bound to the dynamic scaling and final steward approval to achieve pretty much the same thing, but better.
From what I recall your hesitation was that it would be difficult to keep track of workers, that problem is shared both with this proposal and my idea and the same methods can be used to mitigate it.
2 Likes
Just a note on this: Tooling and processes are less effective without a cultural or social build. I will say sometimes we are focusing a lot on creating processes and which tools would be the best, but at the moment I only see it effectively on stewards or “people on the know” roles. The same effort that is put on the proposal side, and the tooling side should be implemented on the cultural side and raising awareness, I feel it’s counterintuitive to let a forum and snapshot be the only space to gather a community to be participant.
As a note, I don’t have all the answers (this is more like a rant). But I agree with this proposal in general terms. A coordination layer is needed not only to create a better organization but also to be visible and aware, so it’s not only about the “tool” to be implemented.
4 Likes
I think the issue with this is that it doesn’t give the stewards much control over who does a job, and it doesn’t give the people doing the work any assurance they’ll be paid. It’s difficult to see how you’d run a swag store, or manage an endowment, using a system like this.
2 Likes
The exact same mechanism used for this proposal can be used for mine to control this. Like I suggested:
Neither does yours.
My idea was actually created to ensure this, two months ago, and it does, more-so than this proposal. There aren’t any further assurances in your proposal to assure people getting paid, than there are in mine, in fact, there are fewer in yours due to my idea solving the expectation of compensation.
No. You’d use the same mechanisms for gating as you’d use here.
I’m not sure I understand your proposal, then. As I understand it, you would have an open bounty, anyone can do the work and then come to the stewards afterwards to be paid. How does this provide assurance they’ll get paid, or prevent multiple people doing the work?
Can you write up parallel examples to the ones I gave, showing how they’d operate under your proposal?
It’s a system intended for closed workgroups. As it stands now, those workgroups contains selected people and aren’t open to the public. I’d share your concerns if the bounties were open to the public.
The same gating mechanisms used for your proposal, would be applicable to my idea and final approval of accepting a task or approving work altogether before payment could easily be in the purview of stewards.
ENS doesn’t have “closed workgroups”. We have elected stewards of each WG, but WG membership is open to anyone.
In that case I don’t understand how your proposal differs from the RFP process.
Can you please provide examples of how it would work in practice, using the examples in my post?
They are ipso facto as closed or open as your proposal entails, neither more nor less.
I think that’s more clearly explained in my original post A Dynamic Task Reward System for Workgroups
I don’t understand what this is supposed to mean.
Your original post doesn’t provide any examples of the process in action either.
I’ll try to think of an intuitive way to explain it by tomorrow afternoon.
I think some worked examples mirroring the ones in my post would be simplest and most illustrative.
I’ve written up a proposed process for dealing with RFPs in this docs pull request. If there are no strong objections I would like to merge it and try the process out with some initial RFPs for stuff we’ve already identified that needs doing.
3 Likes
I like the concept and specially having always a clear ownership model of proposals.
I do think however that not all RFPs should be DAO wide. Funding a swag store should be coming from the ecosystem group, and only if that is not happening should there be a wide snapshot vote to tell them to do it.
3 Likes