Contribution Guidelines + Proposals for New and Ongoing Projects

đź’¬ General
1

Let me preface this post by saying I’m excited about the DAO’s core values: open-source, collaboration, teaching, learning, and working on cool projects with cool people around these ideas. But obviously, there’s a lot to go over, create consensus on, and build before we have a clearer path of where to go and how to achieve what we, as a collective, wrap our efforts around.

Having said that, I think there’s something we should nail from the start, and that is collaboration. More specifically, learn to harness the skills and enthusiasm of everyone joining the DAO so it becomes a bit more engaging, productive, and proactive as a collective. And guidelines/frameworks would be perfect for something like that.

I know this isn’t easy, and probably a lot to nail down in Season 0 of the DAO but I think there’s a lot of value in working on this from the start - correct me if I’m wrong.

Also, don’t want to put any pressure on people already working on this. Recently went over the Proposal for Season 0 and General Proposal Template, to understand a bit better how to propose this more effectively. (Love the ideas, by the way, thanks to everyone who worked on that).

Anyway, recently saw many newcomers and not-so-new DevDAO members asking how to contribute to ongoing projects or trying to push/propose new projects the DAO may benefit from (including myself).

The questions/proposals below are about some of these concerns and overall collaboration (as someone who hasn’t contributed to open-source projects yet -like probably many who have joined- and would love some guidance).

  1. What would be the minimum-viable project to add to the DAO? And how would we decide which projects to work on?

The proposal draft for Season 0 goes over some of that, but there’s still some specificity to mention. For example, say someone proposes a project and one other member says they’re interested. Then both start working on it and release a small MVP.

If only these two people worked on that and released something - will the rest of the DAO accept it or does it need to match certain factors (code quality, a design system, full functionality, etc.)? Should more people also work on that to be accepted? How will we decide if a project is good enough (voting, general consensus, etc.)?

We will probably need a scalable way to measure this. For example, a way to vote on projects and decide who will work on them.

  1. Would a contributing guideline or framework help?

Having a guide that people can follow to understand where to start contributing (a list of available projects), how (what rules to follow regarding contributions), etc. would be helpful. I’d love to just have a step-by-step or bullet-point guide I can follow to know whether I can contribute to something and how to start.

The same would be great for starting projects. For example, what kind of projects would be accepted as proposals (obviously the main idea is mostly behind learning, teaching, and increasing opportunities for members), will a semi-complete project be accepted or should it be started from the DAO first? Should all projects be completely open-source? What about frameworks and tools to use (will WordPress, for example, be acceptable? Hope not!)

This should be on the website, Discord, and DevDAO repo (once we have it ready).

P.S.: These are the questions I could come up with right now, but I’m sure others will come up later. I don’t expect to get all the answers right away and there’s probably a lot of work to do and stuff to think about - but still wanted to give my two cents about this part of the DAO.

Let me know what you guys think :slight_smile:

7 Likes
2

These are some great thoughts & questions! I do think a lot of this can be ironed out in Season 0 as we determine the process for many of these things. This post will be a great starting point for the groups that begin deeper communication around this.

3 Likes
3
  1. What would be the minimum-viable project to add to the DAO? And how would we decide which projects to work on?

I recently read a great thread on Twitter that I think is relevant here: https://twitter.com/JulzRoze/status/1454114301128626176

One point in particular stuck out to me:

So how do DAOs create space for new leaders to emerge?

Allow people to codify (podify :wheel_of_dharma:) nuclei of activity in DAOs so community excitement can directly translate into effective and valuable contributions.

In my mind, the key to building a successful community of builders is to make it as easy as possible to go from “idea that members are excited about” to “SHIP IT”.

And I think the way we make that easy is for the DAO to get out of the way as much as possible (in terms of rules, processes, etc.).

If members are excited and want to start working on something, we should provide the resources they need to get moving: Discord channel, GitHub repo, bots, apps, etc.

The vast majority of resources that a project needs to start shipping don’t cost us anything, and so we shouldn’t impose our own cost to them by requiring too much of new projects. Support them in getting started by giving them what they need and allowing them the autonomy to decide for themselves what sort of process they want, code standards they want to follow, etc.

  1. Would a contributing guideline or framework help?

Yes, absolutely! I think each project should be encouraged to follow a similar contribution model. I think we’ll figure this out as we go, but I agree that once we figure it out, it should be documented and made publicly available.

1 Like
4

I should also note that I view “official Season projects” and “community-created projects” as entirely separate things.

Season projects will have lots of “process” around them (design system requirements, code quality checks, etc.) which makes sense because the intent is to have large groups of people working on a single project at the same time.

I think community-created projects should receive as much support as we can afford to give (especially as they gain contributors/adoption) but they’ll be better off if we allow them the autonomy to make their own decisions. I think over time they’ll be more likely to adopt the processes of Season projects anyway, but for the time being, getting things moving is more important than imposing costs to starting.

2 Likes
5

I’m about 99% onboard with “ship it” mindset, and I think we should certainly endorse “BUIDL” as a core way to engage with the DAO and web3 (and learn things along the way - look at that, we’re self-educating! core mission!).
My 1% objection is about keeping the D_D brand strong. If D_D is releasing something, I (and probably the DAO) want to make sure that we’re putting out a quality product that is in line with what D_D stands for (ref: mission, values, goals). To me, the solution to that is to have a 2nd tier of D_D Community projects.

Some considerations

  • This can serve as the launching point of almost everything that the DAO moves to do in the future
  • I have no idea how handing off from one org to another looks in github
    • This might be a terrible overhead to manage with PRs and such, depending on how permissive permissions can be set
  • We don’t have to police everything being built in D_D Community as it’s not official DAO products, nor try to keep the consistent stack / UI / etc
  • Greatly reduces the barrier to entry in terms of community organizing in order to build something that a dev thinks is a great idea
2 Likes
6

This sounds like a great idea.

In my mind, something like “Official DAO Projects” and “Upcoming Projects” also makes sense. The former will be in the hands of Core Teams as explained in the Season 0 proposal. And the latter would be projects members are starting on their own side with the potential of becoming Official DAO Projects.

Official DAO Projects = already market-tested web3 projects (proof-of-skill, job board, etc.) or useful internal DAO stuff (internal tools, teaching/learning platform, derivatives and NFTs, internal gigs, etc.). These will have to meet certain standards regarding tools/frameworks used, code quality, and design systems. People who started the project will keep working on them as part of the DAO with core team members overseeing development and helping wherever they can.

Upcoming Projects = anything members want to create that helps the DAO directly or indirectly. These would be more like ideas to test and see how far they go. People can use whatever tools/frameworks they can, and their purpose will mainly be to find a market or solve an internal issue within the DAO. Once they’ve become self-sustaining projects or something the DAO needs to function, we can then declare them official DAO projects (as long as they meet the standards).

This would be a great place to start IMO. Thus, people can already have an idea of where to start. Also, pushes people to try hard and make things work (and automatically prevents useless or non-active projects from becoming official).

7

As for the overall guidelines, I see there’s some people looking for information about projects and how to contribute.

IMO, we may need to brainstorm some ideas and get them on a doc.

ALSO, wouldn’t hurt to add a “Projects in Progress” or something similar on the website (with all the projects already being worked on the official DAO repo). While Discord makes it easy to separate projects and categorize stuff, it’s not the friendliest UX - something the website may do a lot better.

1 Like
8

Love the initiative getting this post up @angel and the enthusiasm to build. YAGMI.

This community has got very big very quickly with no pre-planning up front. That presents a lot of challenges for how we organise to be successful. A really good read for thinking about this is @willblackburn 's post - If you want to go fast go alone, if you want to go far go together, if you want to go nowhere start a DAO.

Absolutely for anyone and everyone just building and as a community us supporting everything that is built by members in every way we possibly can. This is something already happening to a degree by providing a space for people to collaborate and also a platform to help promote those ideas.

Inline with @gjsyme 's thoughts, my feelings on where the distinction should lie re DAO vs community projects is where something is going to be branded under D_D. Any group should be able to propose a project that could sit under the D_D brand but they should seek first quorum/support from the DAO as whole.

The threshold for a project becoming a “Core Project” should have nothing to do with code standards, framework used, it should be is this inline with helping achieve our mission, values and goals, and does the community as a whole support this specific idea and the specific implementation being suggested.

The Core Team is not proposed to dictate these projects, it is proposed to implement the tooling and process required to make make decisions on what we create together as a community, as well as provide some direction and leadership early on, to keep us inline with our mission, values and goals.

Hopefully we can get support to move forward and start tackling this big questions in the coming weeks :slight_smile:

1 Like
9

I should clarify… whilst standards, code frameworks etc. shouldn’t matter in deciding on a Core Projects, we should probably have some standards for projects that are accepted one.

2 Likes
10

Hello! Could someone guide me what’s the procedure to join DAO and contribute? I’m a student and frontend developer, learning solidity. Would love to get involved!