search

Developer-DAO / DAO-job-board

A job board connecting DAOs with talent.
https://devdao-job-board.vercel.app/
82 stars 34 forks source link

Roadmap + MVP Features #35

Closed 4gnle closed 2 years ago

4gnle commented 2 years ago

Hey everyone!

The job board is already shaping up, things are looking neat so far and there's a thing or two to finish before we launch the MVP.

But there's a tiny issue - even though it already has a shape, we still should make it CLEAR what we want the website to be like before we launch it.

After talking to @with-heart about this, it makes sense to DEFINE what the ideal MVP should look and be like.

For that, it would be great if we develop a roadmap for the job board, starting with WHAT the MVP should have at first and HOW we can achieve that (a step-by-step list).

With that in mind, let's get into a few points I had in mind:

ACCESS TO THE JOB BOARD

The job board MVP should be only for DAO members first. This way we can iterate faster without having so many people using the site (and get feedback directly on the Discord). Of course, we may need to develop a way to authenticate those who own an NFT.

Later, if we decide to open the job board for everyone, this authentication feature could help us identify who belongs to the DAO via tags or icons, for example.

NOW, how should people authenticate? According to what we first had in mind, authenticating via Metamask using Supabase to store data would be a decent approach. This way we aren't entirely web2 and we have a way to authenticate only members from the DAO if we want.

What do you guys think?

JOBS

With the previous point in mind - we should decide whether we want the MVP to have both Gigs and Jobs, or only Jobs. So far, I've seen people asking for help in personal projects (gigs) and others posting job opportunities on companies they're working on (jobs) on the #jobs channel in Discord. Of course, having both Gigs and Jobs will be a bit more of work, but it also makes the site more complete.

What are your thoughts on this?

P.S. We already have both pages almost completely done.

GIGS

For Gigs, we also need to figure out how the application form/website flow looks like. Gigs should have their internal application through the site.

Now, how can we ensure devs get paid for their work? Or at least they get a reward for their efforts?

Most bounty systems I've seen so far have their internal payment systems (with their coin). We should probably develop something like that.

Because of this, there are two paths (IMO) we can take:

  1. A reward/payment system is a lot of extra work, and we still don't have a coin to work with, so we should probably delay the Gigs part of the website for now and focus on the Jobs board instead.

  2. Otherwise, we could use the Gigs page to help people looking for help to connect with those who want to help (without a payment/reward system... yet).

APPLICATIONS

How does the application feature look like for Jobs and Gigs?

For Jobs, my first idea was to let companies and people opening job posts add their email/webpage posts so devs can apply to jobs DIRECTLY and leave the job board only for posting. Now... should we also develop an internal tool for these applications? This will let companies see who applies through the job-board site - separating DAO members from everyone else who applies directly on their page/email.

For Gigs, I explained a quick approach on Issue #26 . In short, add a simple application form with a proposal input (where devs write what they offer), proof they can handle the job (with links to repos/websites/etc), and a plan form where they explain how they will tackle the gig.

DESIGN

The first few pages in what we already have for the job board were designed taking into consideration the main developerdao.com site as an example.

The colors, boxes, shadows, and fonts were all taken from there. However, it probably doesn't look perfect for the job board. We should probably strive for something simpler (especially now the main DevDAO website is getting a re-design).

I'd suggest proceeding with a simple black-and-white theme instead of the current bluish/grayish tones in the site.

HAVING SAID THAT, we should probably develop a design system. This would be the job of the #design-guild back at the Discord. Once we have the MVP rolling, that re-design may come helpful to make everything clearer. (Or maybe even before the MVP rolls out?).

Anyway, we're taking feedback + recommendations for this. If you belong to the DAO and want to give your two cents, feel free to comment on this issue.

DEADLINES

Also, we should probably come up with a deadline for the MVP. Not to put pressure on ourselves, but developing stuff without a clear date and/or idea of what we want to do could make it impossible to finally ship. However, it shouldn't be something too close either (most of us have either full-time jobs or other responsibilities).

I'd propose getting the MVP rolling within 2 weeks. This way everyone has enough time to contribute while also giving us enough space to test stuff out before releasing it.

The website is pretty simple still, but 2 weeks seems like a fair timeframe - right? What does everyone think?

ROADMAP

The points above are mostly my concerns + ideas so far. Once we figure them out (preferably within a few days), we can proceed with the writing of the roadmap so we're all in the same page when it comes to designing and developing the website.

Now, how should we write the roadmap? I propose creating a ROADMAP.md in the repo. Whatever we end up having a consensus on, we'll write on that roadmap.

To speed up the roadmap process, I'd propose the following step-by-step list for the MVP roadmap:

    • [ ] Develop the MVP with a simple design (black and white as said above) + only the Job posting page. Only DevDAO members will be able to apply to jobs for now (via the company's emails or their website posts). We should have this by the 30th of November.
    • [ ] Iterate and make changes on feedback from members using the site. This would be ideal to perfect the job posting + application system as we go.
    • [ ] In the meantime, we should figure out how we want the Gigs page to look and work. So far, my idea was to make a smart contract (once we have our own DAO coin or using an ETH L2) so people creating gigs can deposit rewards and developers working on those gigs can receive them directly. Once we have that ready, release the Gigs MVP to the public (likely before the year ends)?
    • [ ] Re-design the page with help from the #design-guild. This would be the last step into the MVP roadmap. Once we have everything working, a re-design that makes the site more usable and easier to work with would be ideal. Most likely will be the design guild who tackles the job.

After that, maybe we can come up with newer features over time - but that's probably enough for now. The re-design will take the site to a new place, so we may still have a lot of stuff to play around with + develop.

Anyway, this is my initial approach to a roadmap + concerns + ideas I think could help us develop the site further.

What do you guys think? @with-heart @carlomigueldy @Dhaiwat10 @miralsuthar @JoviDeCroock @swetshaw

Feel free to comment on every/any subject I went over. Also, it'd be great to come up with your roadmap so we can brainstorm as we go.

Consider Carlo's approach: Issue #33

carlomigueldy commented 2 years ago

NOW, how should people authenticate? According to what we first had in mind, authenticating via Metamask using Supabase to store data would be a decent approach. This way we aren't entirely web2 and we have a way to authenticate only members from the DAO if we want.

Sounds good to me. I have a suggestion for how we can implement this, we can probably use Next.js's serverless function and use a Supabase client into it using the service role key, and from there it will handle making calls to DevDAO smart contract and to check if they hold a genesis NFT (at least that's what we can do for now since ERC20 governance token hasn't been launched yet) and when they do we can then add those tags. e.g. Genesis

For JOBS & GIGS, I think we can focus on the jobs first than gigs as you mentioned we may need to build a system to ensure to incentivize devs for their work.

The website is pretty simple still, but 2 weeks seems like a fair timeframe - right? What does everyone think?

Yeah sounds good. Also I think January is like the perfect time for looking new jobs, so we should launch an MVP before January as to where most job postings are created around that time.

swetshaw commented 2 years ago

GIGS For gigs, I agree with the first point, let's focus on building the job board first, once the MVP is released, we can take up the part of the gig.

A reward/payment system is a lot of extra work, and we still don't have a coin to work with, so we should probably delay the Gigs part of the website for now and focus on the Jobs board instead.

APPLICATIONS

APPLICATIONS How does the application feature look like for Jobs and Gigs? For Jobs, my first idea was to let companies and people opening job posts add their email/webpage posts so devs can apply to jobs DIRECTLY and leave the job board only for posting. Now... should we also develop an internal tool for these applications? This will let companies see who applies through the job-board site - separating DAO members from everyone else who applies directly on their page/email.

I have a suggestion here, since we are working on company profile, how about we modify the job creation flow like:

  1. Company creates their profile (If they haven't already)
  2. Company creates job post 2.a. In the job application form, we can put a dropdown from where the Company can select their name (since they have already created their profile)

This would be helpful in listing the jobs on the company's page. What do you all say?

DESIGN

I'd suggest proceeding with a simple black-and-white theme instead of the current bluish/grayish tones in the site.

I realized that there is an issue in using a black and white theme while creating Figma designs for company profile (check Figma files here)

Issue:

  1. The company logos are of varying colors, if it's black and white, well voila! it fits. But if they have a different color, do you think it will go well with a black and white theme?

If you think it goes well, we can move ahead.

DEADLINES

The website is pretty simple still, but 2 weeks seems like a fair timeframe - right? What does everyone think?

2-weeks is good enough. Agree with this 👍.

ROADMAP

Consider Carlo's approach: Issue #33

I seriously think we should follow this and come up with user stories and document them somewhere, once everyone agrees to the user stories, we can fix them there and then go ahead with the road map that you suggested. The roadmap looks good to me 👍

Dhaiwat10 commented 2 years ago

Of course, we may need to develop a way to authenticate those who own an NFT.

Let's not waste resources on this. I have no issues with us only getting feedback from DevDAO members at first but we don't need to spend any time on making sure only DAO members can access it. It's fine if someone else can access it.

A reward/payment system is a lot of extra work, and we still don't have a coin to work with, so we should probably delay the Gigs part of the website for now and focus on the Jobs board instead.

Totally agreed. Let's put the gigs part on hold for now.

For Jobs, my first idea was to let companies and people opening job posts add their email/webpage posts so devs can apply to jobs DIRECTLY and leave the job board only for posting. Now... should we also develop an internal tool for these applications? This will let companies see who applies through the job-board site - separating DAO members from everyone else who applies directly on their page/email.

I want to re-iterate the original purpose of this project: to make a job board that connects talent with DAOs. Let's not forget that this project is supposed to be used by DAOs and not companies.

The website is pretty simple still, but 2 weeks seems like a fair timeframe - right? What does everyone think?

3 weeks would be more ideal.

with-heart commented 2 years ago

To echo @swetshaw's comments, writing detailed user stories and coming to agreement on them is important for us to move forward together and for us to build a sensible user experience.

With that said, I think even 3 weeks is really underestimating how much time the "meta" tasks like fleshing out user stories will take (and that's ignoring how much more time actual development takes than we tend to estimate). Which leaves me wondering: do we really need a timeframe at this point in time?

imo there's no benefit to completing the MVP by a set date. We can create the user stories, work our way through them, share ideas and progress with users through Vercel preview deploys, and iterate until we've nailed the core product.

It's complete when we feel like we've built what we set out to build, not because of some arbitrary timeframe that may or may not be accurate.

Additionally, as the guild "leader", I'd really like to encourage yall to take the time not only to build this MVP but to build it in a way that others can learn from you and the process:

If I was going to assign a score to guild projects, a large chunk of it would be around how effective the project was at teaching others, getting new contributors involved, and documenting all of the pieces as we go (issues, pull requests, code reviews, README.md, ROADMAP.md, etc.) so outsiders can understand the project nearly as well as those working on it.

Not that my score matters! Yall can do what you like (which is why I'm guild "leader" and not guild LEADER), just want to throw these thoughts out there and hope that you'll consider the value in trading speed for leveling up your fellow guild members.

You're our first real guild project so I think there's an opportunity for yall to set a good standard for what a healthy, effective project looks like that future projects can follow. But only if you care to! If you just wanna rapidly build cool shit, that's totally fine too—I'll contribute and support yall no matter what :)

with-heart commented 2 years ago

Now, how should we write the roadmap? I propose creating a ROADMAP.md in the repo. Whatever we end up having a consensus on, we'll write on that roadmap.

I'm thinking a GitHub Project might be more effective for this. Certainly not opposed to documenting the general direction and purpose of the project in ROADMAP.md (I LOVE Markdown so I'm always in favor of another md file 😁), but text is static so it's hard to track progress.

Basic workflow could look something like this:

4gnle commented 2 years ago

To echo @swetshaw's comments, writing detailed user stories and coming to agreement on them is important for us to move forward together and for us to build a sensible user experience.

With that said, I think even 3 weeks is really underestimating how much time the "meta" tasks like fleshing out user stories will take (and that's ignoring how much more time actual development takes than we tend to estimate). Which leaves me wondering: do we really need a timeframe at this point in time?

imo there's no benefit to completing the MVP by a set date. We can create the user stories, work our way through them, share ideas and progress with users through Vercel preview deploys, and iterate until we've nailed the core product.

It's complete when we feel like we've built what we set out to build, not because of some arbitrary timeframe that may or may not be accurate.

Additionally, as the guild "leader", I'd really like to encourage yall to take the time not only to build this MVP but to build it in a way that others can learn from you and the process:

  • stream in public on Discord and take the time to answer questions, explain what you're doing, etc.
  • pair with users when building a feature (the pairing spreadsheet could be really helpful in finding potential partners!)
  • share issues, user stories, etc. on Discord and help others get involved in the conversations around them
  • write detailed pull request descriptions and give each other thorough code reviews so that we're sharing context—not only with each other, but with new contributors who may be following along

If I was going to assign a score to guild projects, a large chunk of it would be around how effective the project was at teaching others, getting new contributors involved, and documenting all of the pieces as we go (issues, pull requests, code reviews, README.md, ROADMAP.md, etc.) so outsiders can understand the project nearly as well as those working on it.

Not that my score matters! Yall can do what you like (which is why I'm guild "leader" and not guild LEADER), just want to throw these thoughts out there and hope that you'll consider the value in trading speed for leveling up your fellow guild members.

You're our first real guild project so I think there's an opportunity for yall to set a good standard for what a healthy, effective project looks like that future projects can follow. But only if you care to! If you just wanna rapidly build cool shit, that's totally fine too—I'll contribute and support yall no matter what :)

This is probably one of the best comments you've made so far mate! THANK YOU!

Given this was a surprisingly eye-opening thing to read for me (WHAT WAS I DOING BEFORE NOT SHARING MY DEV PROCESS...??), I suggest we start a new contribution guide for the DAO. It'd be great if everyone gets to understand what is expected when contributing and how they can contribute in the most effective way possible.

Apart from that, everything sounds exactly like what we should do going forward. The deadline was mostly to impose a bit of urgency so we finally ship this product. However, I'm pretty sure it was me just projecting (I've been procrastinating on a few tasks related to this repo lately tbh)

ANYWAY, now we're on a clearer path forward. For now, I think we probably need a way to "vote" or create general consensus on everything. User stories seem like the best way to come up with new ideas and validate them. But how can we make sure every one of us is on the same page?

4gnle commented 2 years ago

Closed this issue because the RFC was created at:

https://forum.developerdao.com/t/rfc-user-stories-for-dao-job-board/507