Skip to main content

Contributing to Giveth Development

Giveth currently maintains three products that focus on funding management, peer to peer donations, and DeFi for-good token economics. These are Giveth TRACE, Giveth.io and the GIVeconomy respectively

All our products share some common development standards that are paramount to learn before engaging in any development for Giveth. In this document we'll show you how to interact with our open-source repositories, getting in touch with the right people and how to begin creating and picking up issues.

Github Management​

First things first, you'll need to install the zenhub extension for github for your web browser that will allow you to see the workspaces and pipelines we use in Github to manage issues.

All-Devs Zenhub Board

We have transitioned to manage all three DApps(products) under one workspace, All-Devs.

Repositories​

The Giveth Github organization has many, many repositories. Here’s a general overview of relevant repositories that relate to our active products:

Product

Repository

Description

Giveth.ioimpact-graphBackend of Giveth.io
Giveth.iogiveth-nextGiveth.io current version
Giveth.iogiveth-io-typescriptGivethio typescript version with new design.
GIVEeconomyGIVeconomyUsually used for planning and issue tracking
GIVeconomygiv-token-contractsSmart contract implementations
GIVeconomyliquidity-mining-dappGIVeconomy Frontend UI
GIVeconomygiv-token-subgraphCalculating $GIV data for GIVeconomy Frontend
GIVeconomygivback-calculationCalculating GIVbacks
TRACEgiveth-dappFrontend and planning of giveth TRACE
TRACEfeathers-givethBackend of Giveth TRACE
TRACEdapp-mailerEmail notification system for TRACE
TRACEgiveth-bridgeGiveth Rinkeby - Mainnet Bridge system
General Servicesui-design-systemnpm package for Giveth design assets

Pipelines on the All-Devs Workspace​

When you enter a workspace on the Zenhub tab you'll see a line of adjacent columns that are used to identify and manage the statuses of issues currently in the repositories. You can find a short description of each below:

New Issues - New bugs and features go here first.

Epics - Pipeline for Epic Issues. Larger tasks comprised of several smaller issues.

Icebox - Features or Suggestions that have been archived. Issues here are non-priority and might be added into sprints only if Devs have the bandwidth.

Backlog - Lower Priority Issues waiting to get pulled into Sprint Planning.

Sprint Backlog - These issues have been vetted and are ready to be worked on. They will be added into the next sprint according to priority and Developer bandwidth.

In Progress - Picked up and being worked on by the Developers, usually on local builds.

Code Reviews - Open Pull Requests waiting for review and eventual merge into the staging server.

info

It’s mandatory to have the code reviewed by one of the core team members, usually your mentor or the one which introduces the project to you can review it, pls ask for review before pushing it to any environment.

UAT Testing/QA - The feature or bug fix is deployed on the staging server for user testing and Quality Assurance.

Done - Bug fix or feature has been completed, and is ready to be deployed on the live server.

info

All issues should meet DoD (Definition of Done) criteria to be approved as Done and being in this column: Success Criteria passed (if it’s get mentioned in User Story / Task or related issue) Deployed in Staging UAT Tested by a tester or PM Documented

Closed - The bug fix or feature has been copied live. It’s recommended that all closed issues get related to a release number in the zenhub and get closed right after the version goes live.

Creating Issues​

Creating Github issues is essential to ensure bug fixes or features are tracked properly and relevant information can be organized, and consolidated. The new issue template is a guide only, feel free to delete any heading that you don't use.

Labels will help add context to your issue, please use them so other developers can get a better understanding of issues at a glance and pick them up. Some commonly used labels in All-Devs are:

fast follow - Priority features or improvements following a product launch or version release.

documentation - Requesting creation or updates of technical documentation.

bugs - Functionality or feature of a product that is broken or not working as intended

feature request - Requesting for a new feature or functionality to be added to a product

design needed - Requesting support from the design team to create assets relevant to this issue

question - There is a pending question inside this issue that needs a response in order to move forward

security - Security issue or improvement

UI - This issue relates to the User Interface of a given product

UX - This issue relates to the User Experience of a given product

Ceremonies​

We host in the Giveth Discord many Developer meetings throughout the week including:

  • Daily Dev Standups from Tuesday to Thursday at 6:30am GMT-6
  • All-Devs Sync weekly on Mondays at 10:00am GMT-6
  • GIVeconomy Sync weekly on Wednesdays at 8:00am GMT-6

These meetings are important places to stay up to date with DApp development and to integrate with the Giveth Team as a Development Contributor.

Sprint Management​

Framework: We’re practicing mostly Scrum, in biweekly iterations (called sprints), sometimes based on project situations we move to KanBan.

What is Scrum?​

In scrum, the sprint is a set period of time where all the work is done. However, before you can leap into action you have to set up the sprint. You need to decide on how long the time box is going to be, the sprint goal, and where you're going to start. The sprint planning session kicks off the sprint by setting the agenda and focus.

  • The What – The product owner describes the objective(or goal) of the sprint and what backlog items contribute to that goal. The scrum team decides what can be done in the coming sprint and what they will do during the sprint to make that happen.

  • The How – The development team plans the work necessary to deliver the sprint goal. Ultimately, the resulting sprint plan is a negotiation between the development team and product owner based on value and effort.

  • The Who – You cannot do sprint planning without the product owner or the development team. The product owner defines the goal based on the value that they seek. The development team needs to understand how they can or cannot deliver that goal. If either is missing from this event it makes planning the sprint almost impossible.

  • The Inputs – A great starting point for the sprint plan is the product backlog as it provides a list of ‘stuff’ that could potentially be part of the current sprint. The team should also look at the existing work done in the increment and have a view to capacity.

  • The Outputs – The most important outcome for the sprint planning meeting is that the team can describe the goal of the sprint and how it will start working toward that goal. This is made visible in the sprint backlog.

sprint planning

Before the iteration starts, you may need to have your expected total contribution hours in Giveth Resource Planning Spreadsheet, the link usually gets shared in the Discord dev channel before the sprint meeting. You can find the sprint sheet and update the following cells:

resource planning spreadsheet

It helps the Product Managers (PMs) to plan for the resources better and know if they are able to meet the milestone in each sprint or not. If you couldn’t find time to fill out the spreadsheet, you may be asked to do so during the meeting or whenever you can have an estimate, just DM it to PMs or put it in the dev channel.

The usual sprint planning goes like this:

  1. PMs bring the issues (Preferably User Stories to the planning meeting, describe it and make sure it’s clear for the team to start implementing.
  2. PM facilitates talks between devs to make it as clear as it can be.
  3. PM asks for estimations in Story Points (Story Points are the unit of minimum effort spent on a product which can be delivered asap, like a simple bug fix, for example, could take half of a working day. )
  4. PM starts building “Sprint Backlog” with prioritizing the issues and makes sure the total amount of Story Points are proportionate with the total capacity of the teams and contributors.
  5. Everyone agrees on the sprint plan and commits to the expected goal.

Key Contacts​

  • Development Working Group Steward - Amin
    • Discord Handle: Amin#2164
  • GIVeconomy Product Manager - Lauren
    • Discord Handle: karmaticacid#1218
  • Giveth TRACE, Giveth.io Product Manager - MoeNick
    • Discord Handle: MoeNick#1374
  • Giveth.io Lead Developer - Mateo
    • Discord Handle: mateodaza#3156
  • DevOps & Security - Kay
    • Discord Handle: geleeroyale#3228
  • Lead Designer - Marko
    • Discord Handle: markop#2007

Installation Guides for Local Development​

Testing Guidelines​

Tools we Use​