Kontribz Builder Journey

[kazai777]

Hi everyone 👋

Here is a project that we intend to create with @mous1985 and @DIGIX666 for the renewal of our grant. If you have any suggestions, questions, or other inquiries, don't hesitate to let us know. Enjoy your reading! 😃

1. Introduction

Create a platform enabling teams to create and manage their bounty with internal and external contributors, to facilitate collaboration between teams and developers. We'll be focusing on how Gno could use it to manage their bounty, and then the aim is to extend the project to any teams wishing to manage their bounty with their contributors.

This allows all kinds of projects to operate openly or privately, and contributors to participate in tasks.

For the visual user interface, we're going to focus on markdown only, to simplify its development, and concentrate on logic rather than visuals. This also enables easy integration of the platform directly into gnoweb.

The main page will group the latest published bounty with the possibility for the user to filter the bounty by amount, creation date, domain, language etc...

The platform will also have its own discord server, whose main purpose will be to create private discussion threads between a developer and an organization to discuss a task to which a dev has been assigned.

2. The Organisations

An organization is a team of 1 or more people. Members of the organization can have different roles: Admin, Reviewers, Manager, Contributors ect... (Accesscotrol.gno)
Each role will have specific rights, e.g. only the Admin and Manager will have bounty creation rights.

The organization will have a profile (profile.gno), with the following information:

• Organization name
• Profile photo
• Organization members (Internal)
• External contributors
• Biography
• Link to external resources (Github, Website...)
• Average payout time
• Reputation score

In addition to the organization's own information, a variety of other information is also available on each organization's profile:

• Suggestions from other users, such as features that would be interesting to have in the project proposed by the organization, or user feedback.
• A LeaderBoard with information on every person who has contributed to the organization.

Before creating tasks, the organization must create a Project with a name and description. The objectif of Projects is to group together the various tasks related to the same project, in the same place.

To create bounty tasks, the organization will first have to choose the type of task and its remuneration from these 4 possibilities:

• Assign task to someone: This option lets you assign a bounty task directly to a contributor who is already part of the organization. This can be useful if you know who you want to assign the task to, or if you want a task to be done by a contributor you already know, with whom you've already worked on similar tasks or others.
• Multiple submissions: With this option, all developers can submit their work, without the organization having to choose which developer to assign to the task. This can be used for a competition, for example, or simply to have a multitude of submissions and select only the best. For multiple bids, the organization has several choices: either it defines a fixed amount and assigns it to a single job. Or it can define different amounts, e.g. one amount for the first job, another for the second and another for the third.
• Open to applications: With this option, developers can submit their applications for the bounty via a form that will be created by the organization with the information they wish to have about the applicant (e.g. previous work, motivation, etc...), and the admin or a member of the organization can analyze the applications and choose the developer they wish to assign to the task.
• Bidding: With this option, developers can submit a bid with the amount they wish to pay for the job. In this case, the organization does not set a fixed price for the bounty, and developers are free to ask for any amount they wish, and the organization will then choose who it wishes to assign to the task according to the bids.

Once the options and the bounty amount have been defined, the orga will have to define various parameters, which are as follows:

• A title
• One or more labels (ex: Backend, FrontEnd, UI/UX ect...)
• A description of the task
• A maximum development time, (ex: 1 week)(optional)
• Choice if the task is for the general public or only for the organization's members and contributors
• Status (To do, In progress)
• Priority (Low, Medium, High)
• Points to distribute (corresponds to the difficulty of the task, e.g. 5 points for documentation and 30 points for something very technical)
• Possibility of assigning a reviewer who is part of the organisation
• Link the task to an issue or PR Github
• The organization will be able to provide a link to open a discord with developers wishing to apply.

Once a task has been created, the organization will have a view of it on a kanban board, enabling it to track the progress of the various tasks.

When the organization has assigned the task to a developer, it will receive a discord link to a private conversation with the developer.

Once the task has been completed, it goes into review, automatically if a reviewer was defined when the task was created, or otherwise, the orga will be notified that the task has been completed and should go into review.

The organisation is then invited to make the payment via the network chosen when the job was created, and an oracle will monitor whether the transaction has been made with the agreed amount in order to mark the job as paid once it has been completed.

Payment

Fractional payment: This option can be very useful in the case of a heavy task that may require a lot of time, with this option the organization can propose, for example, payment of a $5000 task in 3 instalments, the aim being to remunerate the developer after part of the task has been completed, until its total completion.

Payments can be made using the token chosen by the organization (e.g. $SOL, $BTC, $ATOM, $USDT etc.). In order to check whether a payment has been made correctly, we're going to set up an Oracle that will check whether the payment between the organization's address and the developer's address has been made. Firstly, this will enable us to avoid conflicts between the 2 parties over payment and guarantee that payment has been made or not. Secondly, it gives us information on the average time it takes for an organization to make a Bounty payment. Later, when the $GNOT is officially released, we'll integrate the ability to pay in $GNOT, and organizations that choose to pay their bounty with this token will be able to automate payment. Payment automation will be fast and transparent, with the organization sending the bounty amount directly to the contract when the bounty is created, and the contract sending the funds automatically to the developer as soon as the task has been validated.

It is also possible for an organization to group together a set of tasks into a single bounty. For example, define a set of 5 tasks that will be paid a total of $1,000.

3. Developers

Developers will have to create their profile by filling in the following fields:

• Username
• Github
• Biography
• Location (optional)
• Areas of expertise
• External link (optional)

The developer user interface also contains the following information:

• The organizations to which the developer belongs, and his/her role in them (contributor, reviewer, etc.)
• The points obtained for the various tasks carried out.
• A Leaderboard based on the points of all developers
• The total amount received for the various tasks carried out

When a developer looks at a task, a thread is displayed in which he can leave a comment and see the comments left by other users on that task.

Developers also have access to a Kanban table, giving them an overview of the various tasks already completed and those in progress.

When a developer is assigned to a task, he receives a discord link to a private conversation between him and the organization that created the task. This allows them to discuss certain details concerning the task to be carried out.

4. Conclusion and Future Vision

The future objectif is to develop the platform to enable all types of project to manage their bounty, and all developers to quickly and easily find projects to contribute to.

We then want to integrate a DAO that can certify the skills of developers based on different parameters, enabling organizations to facilitate the task of assigning tasks when they receive applications.

Another step we'd like to integrate as soon as possible is the possibility of paying in $GNOT, to integrate automatic payment via a smart contract within the dApp, to increase speed and ease of payment.

[thehowl]

I haven't reviewed this yet, just wanted to point out that deel is a quite well-known company, so a different name is in order.

[mous1985]

We went through a lot of names, but most were already taken. This one was just a placeholder to get the idea across, but we're working on finding something original

[moul]

I've suggestions:

• Remove the concept of token transfer, allowing us to create bounties using dollars (just a field) immediately, rather than only non-valued tokens. We can add the token system later.
• Design it like a factory where communities can establish their own bounty boards.
• Eliminate the web interface and focus solely on markdown, enabling use in gnoweb. Additionally, include the core team's board on the homepage.

Inspiration -> dework.xyz.

[mous1985]

Thank you for your suggestions! We really appreciate your feedback and are currently working on incorporating your ideas into the project, aligning them with current needs.

[thehowl]

I renamed this just so we can have something to refer to when we talk about the project.

[thehowl]

Taking a look. A few notes.

To validate the skills of the profiles, we plan to integrate a DAO responsible for certifying a developer's expertise in a particular topic or programming language. If a developer has their skills validated by the DAO, they will, in turn, be authorized to validate the skills of other profiles in the same fields as theirs. To expedite the validation of completed tasks and projects, experts in a language or topic will be able to review the work provided by the developers.

I suggest you don't necessarily focus too much on this point... the reason why I say it is that we have real-life examples of how these things work and how they don't, really: hiring developers still is a long, complex process, and the nature of the work we do prefers longer-term relationships where developers take time to fully understand and integrate with projects, rather than trying to break down projects into all small individual tasks that can be handled by thousands of different contractors.

The real life examples are degrees, certifications, tests. Unfortunately all of these are subject to Goodhart's law; and many great engineers haven't gone through formal certifications (including my certifications, which are virtually non-existent). I doubt that a DAO providing certifications can work better than universities and other certifications from schools or institutes, which have devoted hundreds of thousands of man-hours in trying to come out with good ways of evaluating people with little result.

Note that this is true also for the microcosm of work and freelance websites. Sure, LinkedIn and Upwork (for example) both have ways to certify knowledge in technologies and programming languages. However, I can assure you, I never read these when looking at a candidate's profile. Previous experiences, work in open source, a documentable past of good work is much more important.

---

We still have bounties for some things, including on the Gno project. They are a good way to try to attract talent into complex problems; and this is where I think there is a place to shine for this project. Let's try to focus on making it a good marketplace which can offer mediation cheaply and fairly compared to platforms like Upwork and Fiverr (which often take cuts of up to 20% the salaries eventually going to the developers, just for the arbitration services they offer essentially).

I see this having a real declination from the Gno project into being a continuation of our bounties. I'd suggest we work towards that idea, and possibly integrate some of the ideas from that system. (public proposals, possible split payments if it is the result of multiple people's work, dynamism in creation of the bounties). Maybe it can work as a double system with a more classic "Fiverr"/upwork kind of thing; but I'd like for you to think how the very open-source approach we took towards bounties can be integrated in a dApp like yours.

I have a feeling that for some portions of the proposal you may have given a pass of it through a LLM. Please don't, I prefer reading something with mistakes and badly-translated french words rather than ChatGPT's aseptic phrasing.

[kazai777]

I suggest you don't necessarily focus too much on this point... the reason why I say it is that we have real-life examples of how these things work and how they don't, really: hiring developers still is a long, complex process, and the nature of the work we do prefers longer-term relationships where developers take time to fully understand and integrate with projects, rather than trying to break down projects into all small individual tasks that can be handled by thousands of different contractors.

For the DAO, the long-term vision for this project is to offer all types of tasks for developers. The idea its create a DAO, for example, would validate the skills of a GO developer based on Github, exercices ect..

With that, the project owner would have the guarantee if the developer proposes to make a go task, these skill have been validated before by expert.

But it’s true, that it requires a lot of thought. As you suggest in your comment, we’re not focusing on that right now.

---

We still have bounties for some things, including on the Gno project. They are a good way to try to attract talent into complex problems; and this is where I think there is a place to shine for this project. Let's try to focus on making it a good marketplace which can offer mediation cheaply and fairly compared to platforms like Upwork and Fiverr (which often take cuts of up to 20% the salaries eventually going to the developers, just for the arbitration services they offer essentially).
I see this having a real declination from the Gno project into being a continuation of our bounties. I'd suggest we work towards that idea, and possibly integrate some of the ideas from that system. (public proposals, possible split payments if it is the result of multiple people's work, dynamism in creation of the bounties). Maybe it can work as a double system with a more classic "Fiverr"/upwork kind of thing; but I'd like for you to think how the very open-source approach we took towards bounties can be integrated in a dApp like yours.

We adjusted the original idea, based on @moul feedback and your feedback. The first objective its focus on the uses that gno could have with this dApp, and after, extend the project.
We’ll take into account how Dework works to adapt our projet.
We’ll update the project description for detail this new vision.

---

I have a feeling that for some portions of the proposal you may have given a pass of it through a LLM. Please don't, I prefer reading something with mistakes and badly-translated french words rather than ChatGPT's aseptic phrasing.

We had written the presentation in French, and for facilitate the translation we use GPT for translate totality, we’ll do it manually next time 😅