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

Streamline & publish process for contributing to QuickPost #24

Open
aurooba opened this issue May 6, 2022 · 2 comments
Open

Streamline & publish process for contributing to QuickPost #24

aurooba opened this issue May 6, 2022 · 2 comments
Assignees
Labels
documentation Improvements or additions to documentation enhancement New feature or request

Comments

@aurooba
Copy link
Member

aurooba commented May 6, 2022

Right now there are a few issues with QuickPost's processes. It was developed quickly and set up as a repository that would only ever have one person contributing to it. While that's likely to remain the case for now, it would be good to have a process that welcomes and eases the ability for folks to contribute if they wish.

To that end, I propose the following adjustments:

  1. Creating a new develop branch which becomes the source of truth for new features and development that haven't been officially released yet. This way the main branch is always the current published version of the plugin.
  2. Creating a CONTRIBUTING.md doc that details how one can go about contributing to the plugin if they so wish.
@aurooba aurooba added documentation Improvements or additions to documentation enhancement New feature or request labels May 6, 2022
@aurooba aurooba self-assigned this May 6, 2022
@aurooba
Copy link
Member Author

aurooba commented May 6, 2022

Develop branch has now been set to default. Next step is to create a contributing doc.

@kkoppenhaver
Copy link
Contributor

Some important pieces of info that should be included:

  • Does the plugin use any sort of coding standard, linter, or any automated tooling that has to pass before a review on the PR should be requested?
  • What (if any) is the convention for naming branches that are going to turn into pull requests? (it looks like from the branches you've made yourself, you already sort of have an add/* or fix/* convention established).

Might also make sense to take a look at one of the GitHub examples.

Going to take a pass at a PR and these are just the things that I thought of while I was going through the process. Hope it's helpful!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants