search

OpenBeta / docs.openbeta.io

OpenBeta official documentation
https://docs.openbeta.io
4 stars 8 forks source link

Create good pr guideline #36

Closed actuallyyun closed 1 year ago

actuallyyun commented 1 year ago

I drafted it based on my understanding and my observations of our PRs. Would love to hear your opinions on it: things to modify, remove, or add.

vercel[bot] commented 1 year ago

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Updated (UTC)
openbeta-docs ✅ Ready (Inspect) Visit Preview Jun 29, 2023 10:08am
vnugent commented 1 year ago

Is this a good place to introduce semantic commit?

https://www.conventionalcommits.org/en/v1.0.0/

There used to be a reminder for new contributors whether they're experienced or not is that:

  1. Fork the repo
  2. Create a branch (Example: fix-234)
  3. Optionally add the upstream remote to their fork

Step 2 is important. While it's not a requirement, it's a good practice to avoid merge conflict headaches.

When they have contributed a few PRs I usually sent them an invite to join the OpenBeta core-dev team which allows them to push to our repos directly.

PR description

Besides attaching samples of good PRs, I think we should explicitly ask contributors to:

  1. Reference the GitHub issue
  2. Attach an "after" screenshot. And if it's not obvious, use a paint program to highlight/annotate the new changes
vnugent commented 1 year ago

It's worth asking contributors to open an issue first before starting on a complex task or enhancement.

From Gatsby.js docs:

https://www.gatsbyjs.com/contributing/how-to-open-a-pull-request

Things to know before opening a PR

We typically recommend opening an issue before a pull request if there isn’t already an issue for the problem you’d like to solve. This helps facilitate a discussion before deciding on an implementation.

For some changes, such as typo fixes or broken links, it may be appropriate to open a small PR by itself.

musoke commented 1 year ago

Is this a good place to introduce semantic commit?

https://www.conventionalcommits.org/en/v1.0.0/

I'm a fan

actuallyyun commented 1 year ago

re: semantic commit

Do you want to make it a must, or a recommendation? @vnugent @musoke

actuallyyun commented 1 year ago

This is a good idea:

Fill out the PR template (Description, Docs, Related Issues)

I think we should have a PR template just as we have one for open an issue.

actuallyyun commented 1 year ago

Is this a good place to introduce semantic commit?

https://www.conventionalcommits.org/en/v1.0.0/

There used to be a reminder for new contributors whether they're experienced or not is that:

  1. Fork the repo
  2. Create a branch (Example: fix-234)
  3. Optionally add the upstream remote to their fork

Step 2 is important. While it's not a requirement, it's a good practice to avoid merge conflict headaches.

This is addressed in the dev onboarding challenge 1. Do you think we should address it here again?

PR description

Besides attaching samples of good PRs, I think we should explicitly ask contributors to:

  1. Reference the GitHub issue
  2. Attach an "after" screenshot. And if it's not obvious, use a paint program to highlight/annotate the new changes

Good idea!