Skip to content

Home base for BuidlGuidl's 10th Batch of Buidlers

License

MIT, MIT licenses found

Licenses found

MIT
LICENCE
MIT
LICENSE
Notifications You must be signed in to change notification settings

BuidlGuidl/batch10.buidlguidl.com

Repository files navigation

Welcome to your BuidlGuidl Batch!

🧨 Congratulations on joining a BuidlGuidl Batch! You've completed SpeedRunEthereum and gotten your feet wet in Scaffold-ETH, Solidity coding, deploying contracts, and basic front-end development. Now it's time to take the next step on your educational journey!

🧙‍♂️ Along with your fellow batch members and BuidlGuidl mentors you'll learn how to collaborate, meaningfully contribute to GitHub repositories, create and handle issues and pull requests, follow best practices in version control, and dive deeper into full-scale dApp development.

🔨 You will come out with all the tools needed to actively contribute to open-source projects!


Table of Contents

  • Introduction
  • Getting Started
    • Selecting Issues to Tackle
  • GitHub Workflow
    • PR Reviews
  • Project Focus
  • Useful Resources

Introduction

Let's get you caught up on what this batch is all about and what you can expect.

Here's what you'll be doing :

  1. You'll start by introducing yourself to the batch and the mentors in a GitHub discussion.
  2. Next, you'll complete Issue #10 and 'check in' to our smart contract by writing a contract of your own.
  3. After that you'll move to Issue #9 and create a personal page and use a pull request(PR) to send it to the batch repo.
  4. From there you will start choosing other open issues to work on, either on your own or in collaboration with other batch members.
  5. The final step is to develop a full dApp! Work alone or group up to create something you think will have an impact. (We will provide ideas on projects you can take on)

We aim to empower you with the skills of dApp development and collaborating with developers, and we will be with you every step of the way.

Getting Started

First, since our contract is deployed to the Optimism chain, you will want to make sure you have some Optimism Eth. The easiest way to get oEth that is to bridge some mainnet Eth to the Optimism chain using the Optimism Bridge. If you need more information or assistance with this, reach out in the Telegram group and we can provide information on why we deployed our contract here as opposed to a testnet or mainnet.

Then you will head to the open Introductions discussion in your batch's GitHub repo and make a post introducing yourself. Also feel free to introduce yourself in the batch Telegram channel as well if you want.

Next head to the Issues tab of your batch's Github repo. Once you complete Issue #1, move on to Issue #2. Everyone will complete the first two issues on their own, then can start taking on the other issues. Work and collaborate with your batch members in both Github and Telegram for a real-world experience. If you're working on an issue, looking to collaborate on an issue, or want feedback on an issue or pull request, shout out to your batch!

😲 Github can seem daunting! Take a look at our detailed guide on the "Fork and Pull" Github process here.

Selecting Issues to Tackle

Issues will be tagged with the type of work entailed, so choose based on the work you would like to contribute. When you decide on one, leave a comment on it that indicates you are working on that issue which helps avoid duplication of efforts. It's also a great way to demonstrate your commitment to the task. Remember this is a learning environment so it's okay if multiple people are working on the same issue concurrently.

Some examples of the issue tags are:

  • (for all): These are issues that everyone in the batch will complete on their own.
  • (good first issue): These will be simple issues that are good for those just starting out.
  • (contract): Smart contract work involving Solidity coding.
  • (front end): Work to improve the front end of your batch's site.

GitHub Workflow

Something important to learn from this is the workflow when collaborating in Github. Here are some good Github best practices:

  • Commenting on Issues: Comment on an Issue if you are working on it to avoid duplicating work. But, since this is for educational purposes, it is okay to work on an already claimed/completed issue for your own experience, or collaborate with others on it. If you run into problems or questions, reach out!
  • Issue and PR Descriptions: In the descriptions of issues and pull requests, try to be as descriptive as possible. Include any relevant information on the problem being solved, and what is being accomplished by any new code you have added. Screenshots and videos can be very helpful with this. This detailed approach makes it easier for anyone to review and handle PRs effectively.

You will all start out by completing issues, but this will change over time and you may want to start creating your own issues for your batch to help with. This is critical in the learning process! Have an idea, bug report, or discussion... Create an Issue!

🚦 Remember: Batch members will have a variety of different experience levels, so contribute where you can, but also feel free to try something new! If you run into roadblocks and problems, talk it out with other members of your batch and the BuidlGuidl mentors!

PR Reviews

👷‍♂️ This batch will start with outside BuidlGuidl members managing the issues and pull requests, but as the batch progresses you'll get the opportunity to step into this role yourself.

So if you want to take your GitHub skills to the next level, start actively engaging in the PR management process. This includes reviewing PRs, participating in discussions, requesting changes, and eventually merging them. This is all part of the GitHub workflow and is very important for effective, real-world collaboration on open-source projects! You may have to shout out to your mentors to get access to accomplish this.

Remember that Continuous Integration/Continuous Deployment (CI/CD) is a crucial aspect of the development process, ensuring that changes are tested and deployed efficiently. The project likely includes automated CI/CD pipelines. These are set up to run tests, check code quality, and deploy updates automatically. It helps maintain code quality and ensures that contributions do not introduce errors.

Project Focus

The final step in the batch will be a project where you will create a full-scale dApp! More information on this will become available from the mentors as the batch progresses.

Useful Resources

To help you make the most of your BuidlGuidl Batch experience, we've gathered some essential resources and guides:

  • Scaffold-Eth 2: A modern, clean version of Scaffold-ETH with NextJS, RainbowKit, Wagmi, and Typescript. Supports Hardhat and Foundry. You can find the repo here
  • Austin Griffith's YouTube: https://www.youtube.com/channel/UC_HI2i2peo1A-STdG22GFsA/videos
  • Scaffold-ETH 2 Contribution Guide: If you're looking to contribute to our open-source projects, this guide provides valuable insights on how to get started. Check it out here.
  • PR Guide: For a detailed understanding of the pull request process, our guide is a great resource. You can find it here.

The Scaffold-ETH2 and PR guides are a great place to start, but you may have to mold the instructions to suit your needs!

About

Home base for BuidlGuidl's 10th Batch of Buidlers

Resources

License

MIT, MIT licenses found

Licenses found

MIT
LICENCE
MIT
LICENSE

Stars

Watchers

Forks