-
Notifications
You must be signed in to change notification settings - Fork 32
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Roadmap + MVP Features #35
Comments
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.
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. |
GIGS
APPLICATIONS
I have a suggestion here, since we are working on company profile, how about we modify the job creation flow like:
This would be helpful in listing the jobs on the company's page. What do you all say? DESIGN
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:
If you think it goes well, we can move ahead. DEADLINES
2-weeks is good enough. Agree with this 👍. ROADMAP
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 👍 |
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.
Totally agreed. Let's put the gigs part on hold for now.
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.
3 weeks would be more ideal. |
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, 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 :) |
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 Basic workflow could look something like this:
|
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? |
Closed this issue because the RFC was created at: https://forum.developerdao.com/t/rfc-user-stories-for-dao-job-board/507 |
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:
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 theJobs
board instead.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
andGigs
?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:
Gigs
MVP to the public (likely before the year ends)?#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
The text was updated successfully, but these errors were encountered: