Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

doc: add contributing guide template #2

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 5 additions & 1 deletion README.md
Original file line number Diff line number Diff line change
@@ -1,3 +1,7 @@
# .github

Default Community Health Files for the Prismic organization on GitHub
Default Community Health Files for the Prismic organization on GitHub

## Templates

To use a template in your project, simply copy the `<TEMPLATE>.md` from the `/templates` directory and add it to your project. Modify it as necessary to fit the specific needs of your project.
121 changes: 121 additions & 0 deletions templates/CONTRIBUTING_GUIDE.md
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ #issue: This file should be named CONTRIBUTING.md to follow this convention.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 #idea: We have a slightly different version for public packages, like @prismicio/client. Note that we replaced mentions of specific Prismic teams with just "Prismic."

What if we had both templates available in this repo?

It would mean my comment above about renaming the file to CONTRIBUTING.md is irrelevant. We could use this naming convention instead:

  • CONTRIBUTING-private.md
  • CONTRIBUTING-public.md

Original file line number Diff line number Diff line change
@@ -0,0 +1,121 @@
# Contributing

This package is maintained by the [TEAM] team. Ask for help or a review in the [#[TEAM SLACK NAME]]([TEAM SLACK NAME LINK]) Slack channel.

## :gear: Setup

<!-- When applicable, list system requirements to work on the project. -->

The following setup is required to work on this project:

- Prerequisite 1
- Prerequisite 2
- Prerequisite 3

## :memo: Project-specific notes

<!-- Share information about the repository. -->
<!-- What specific knowledge do contributors need? -->

> [!TIP]
> Please update this section with helpful notes for contributors.

## :construction_worker: Develop

> [!NOTE]
> It's highly recommended to discuss your changes with the [TEAM] team before starting.
>
> A short discussion can accelerate your work and ship it faster.

```sh
# Clone and prepare the project.
git clone [REPO SSH ADDRESS]
cd [REPO NAME]
[DEPENDENCY INSTALL COMMAND]

# Create a new branch for your changes (e.g. lh/fix-win32-paths).
git checkout -b <your-initials>/<feature-or-fix-description>

# Start the development server.
# Run this command while you are working on your changes.
[DEV SERVER COMMAND]

# Build the project for production.
# Run this command when you want to see the production version.
[BUILD COMMAND]

# Lint your changes before requesting a review. No errors are allowed.
[LINT COMMAND]

# Format your changes before requesting a review. No errors are allowed.
[FORMAT COMMAND]

# Test your changes before requesting a review.
# All changes should be tested. No failing tests are allowed.
[TEST COMMAND]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think i'd separate tests from development.
As it can be a very messy part so i'd make it separated on his own.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a good idea since some repos require a specialized setup. Packages usually have very small requirements (just run npm run test), while services can have large requirements (run a server + configure .env + run the script).

```

## :building_construction: Submit a pull request

> [!NOTE]
> Code should be reviewed by the [TEAM] team before merging.
>
> Request a review in the [#[TEAM SLACK NAME]]([TEAM SLACK LINK]) Slack channel.

```sh
# Open a pull request. This example uses the GitHub CLI.
gh pr create

# Perform a review within your team. This review should at least consider
# the PR's general direction, code style, and test coverage.

# Once approved, request a review from the [TEAM] team in #[TEAM SLACK NAME].
# This second review should verify the pull request is not missing crucial
# logic.

# When ready, PRs should be merged using the "Squash and merge" option.
```

<!-- FOR SERVICES: -->
<!-- Delete this section if not applicable. -->

## :rocket: Deploy

Deployments are broken into three stages: development, staging, and production.

#### Development environment

<!-- Describe how to deploy this service to the development environment. -->

#### Staging

<!-- Describe how to deploy this service to the staging environment. -->

#### Production
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we specify that

  • only the main branch of services is to be deployed
  • it's people's responsibility to make sure their PR doesn't break production or other services (by running CI, creating tests, ...)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know if a rollback strategy make sense to add here but. could be a good addition

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we specify that only the main branch of services is to be deployed

I think this info is specific to each service, so we can probably leave it out of the template. It can be mentioned in the "Production" section.

Should we specify that it's people's responsibility to make sure their PR doesn't break production or other services (by running CI, creating tests, ...)

Yes, that is a good addition, similar to the "no failing tests are allowed" line in the "Develop" section. It could be added as a Caution block. immediately after the "Production" heading.

I don't know if a rollback strategy make sense to add here but. could be a good addition

Makes sense to me as part of the Production section.

This guide should be short and concise while providing enough information to get started. The last thing someone wants to do when they start working is read a bunch of documentation. 😅 Do you have an idea of how we could do that?


<!-- Describe how to deploy this service to the production environment. -->

<!-- FOR PACKAGES: -->
<!-- Delete this section if not applicable. -->

## :rocket: Publish

> [!NOTE]
> Ask the [TEAM] team ([#[TEAM SLACK NAME]]([TEAM SLACK NAME LINK])) for [npm](https://www.npmjs.com) publish access before continuing.

```sh
# Checkout the master branch and pull the latest changes.
git checkout master
Comment on lines +107 to +108
Copy link
Member

@angeloashmore angeloashmore Jun 14, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 #idea: Repositories use main as the default branch now. Maybe we can use main instead of master in the template.

git pull

# Perform a dry-run and verify the output.
# If it looks good, release a new version.
npm run release:dry
npm run release

# Or release an alpha.
# Perform a dry-run and verify the output.
# If it looks good, release a new alpha version.
npm run release:alpha:dry
npm run release:alpha
```