Contributing to GoodDollar

Contributing to GoodDollar

Thank you for your interest in contributing to the GoodDollar initiative.

Everyone is welcome: Developers, designers, and entrepreneurs with a passion for decentralised technologies and a vision to build a new world that has equality, security, inclusivity, and innovation as its cornerstones.

Contributing & Community, Building something on GoodDollar?

Are you already building, have an active project, and are considering integrating G$?

Check out the ongoing GoodBuilders program, offering mentorship and funding to help promising projects grow. Any project that demonstrates meaningful new integrations with the GoodDollar Protocol is eligible to apply!

Learn more about GoodDollar by reading the GoodDollar docs.

(Technical/Builder) Questions? Join the GoodBuilders Telegram Channel to share your ideas, or ask for development support.

Other initiatives for Builders

Scoutgame

We offer rewards for contributions to GoodDollar repositories through our Scoutgame Program. Look for issues labeled with scoutgame in the participating repositories to get started!

Gardens Pool for Open Source Contributors

Once you have some experience working with our repositories, you might have ideas of your own to build. We encourage builders who want to get more autonomy in choosing what they build or contribute to our different SDKs or dApps. Read more about how to propose your own features/contributions on our Gardens Pool

Notes:

1. The GoodDollar project is distributed across multiple repositories. Try to file the issue against the correct repository.

2. Please note we have issues and pull requests templates, make sure you follow them to ease the contribution process.

Getting Started with Contributions

1. Fork and clone the repository

2. Create a feature branch for your work

3. Make your changes following the existing patterns

4. Test thoroughly using the demo applications

5. Submit a pull request with clear descriptions

Issues

Issues are always welcome. Feature requests, bug reports, documentation improvements and any other kid of contribution will be triaged and worked on according to the GoodDollar community and maintainers prioritization and best effort.

Pull Requests

In general, GoodDollar project follows the GitHub flow.

1. Fork and clone the project locally.

2. Create an upstream remote and sync local copy before branching.

3. Use individual feature branches for each separate piece of work.

4. Code changes and tests accordingly. Writing good commit messages, making sure tests pass, maintaining coverage level and following existing documentation.

5. Push to origin (fork) repository.

6. Create a new PR following the pull request template.

7. Work with maintainers on code review feedback.

Scoutgame Developers

For the most part, you can follow the contribution guidelines written below.

Full description about the scoutgame and participation can be found here: GoodDollar Partner Rewards

Any support needed during your time building?

• For high-level questions the comment section of the issue you are working on is a good place to ask them.

• More in-depth questions or support required. Please join the scoutgame support channel.

• It's suggested to join the scoutgame channel anyway once you start contributing. Updates around new tickets and other opportunities will be shared in this channel first.

Some general rules

• We expect that after being assigned, we will see progress happening. Show some progress at least once a week. This can be done through draft pr's.

• We will try to reach out and follow up if we don't see progress. But if, after seeing no progress and no response to feedback, we will unassign someone after 5 days of no response.

• Don't resolve comments generated by either AI or one of the maintainers. Just comment you have done the requested change, or explain why the maintainer or AI might be wrong.

1. Understand the Repositories:

   • Familiarize yourself with the architecture and functionality of the repository from which you take an issue.

   • Read existing code to understand structure and best practices. Always try to follow similar patterns / re-use existing helper methods.

   • If UI, verify if there are existing components you can utilize, and make sure your addition fits into existing design.

2. Select and Understand the Issue:

   • Review the reported issue carefully to ensure clear understanding.

   • Clarify any uncertainties by asking detailed questions—don't hesitate to seek guidance.

   • Ask, Ask, And Ask again

3. Fork and Clone:

   • Fork the repository.

4. Reproduce the Issue:

   • Run the existing codebase and reproduce the behavior or issue reported.

5. Prepare and Learn:

   • If the coding language or technology is new, complete a brief introductory course to familiarize yourself.

6. Implement Your Solution:

   • Develop your solution based on the issue's requirements.

   • While we don't enforce strict rules, we kindly expect adherence to the default principles of the frameworks and languages in use.

   • Seamlessly integrate your solution into the larger codebase—if existing code can be utilized, please do so!

   • For UI components: If no UI is provided, feel free to craft your own design, keeping in mind essential UI/UX principles.

   • If you're unsure about any part of the process, implementation, or a decision to make, we're here and more than happy to guide you.

7. Documentation and Examples:

   • Provide clear documentation and, if applicable, relevant examples or demonstrations of your solution.

8. Submit Your Pull Request (PR):

   • Clearly mention the issue in your PR and describe your solution thoroughly to facilitate quicker reviews.

   • Make sure to add the '#' reference to exact issue.

   • If a new feature involving UX/UI is added, show a demo video, or screens. Most of our apps are usable on both desktop/mobile, so make sure they are responsive.

   • Respond promptly to feedback from maintainers and incorporate requested changes.

   • Make sure there are no build errors and typings are applied correctly (most of our projects use TypeScript). Utilize existing linting configuration like prettier and eslint.

     • If using VSCode, you can for example use the esbenp.prettier extension

     • in the root of the project

     • add a folder .vscode

     • in .vscode, add a file settings.json

     • add the following settings:

{
  "editor.defaultFormatter": "esbenp.prettier-vscode",
  "editor.formatOnPaste": false, // required 
  "editor.formatOnType": false, // required
  "editor.formatOnSave": true, // optional 
  "editor.formatOnSaveMode": "file", // required to format on save
  "files.autoSave": "onFocusChange", // optional but recommended
  "editor.codeActionsOnSave": {
    "source.fixAll": "explicit"
  },
"[typescriptreact]": {
  "editor.defaultFormatter": "esbenp.prettier-vscode"
}, 
"[jsonc]": {
  "editor.defaultFormatter": "esbenp.prettier-vscode"
}
}

A big Thank You!

Your contributions to this project, whether large or small, take this initiative a step closer to the ultimate purpose of reducing wealth inequality through blockchain technology. Thank you for taking the time to contribute.