Giters

NavidK0 / SimpleGraphQL-For-Unity

A simple graphQL client that allows one to use .graphql files (or code) for queries, mutations, and subscriptions with Unity.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Add a contributing.md

johanhelsing opened this issue · comments

commented

@NavidK0 Just wondering how you prefer things to be done?

Things like:

  • Is breaking changes ok (bumping major version of course)? Or do you prefer to avoid this as much as possible?
  • Now that I get write access, do you still prefer changes to go through PRs?
  • Other things?

Might make sense to put this in a contributing.md.

commented

For now:

  • Is breaking changes ok (bumping major version of course)? Or do you prefer to avoid this as much as possible?
    We should follow semantic versioning. So if we make a major breaking change (that isn't just removing deprecated APIs), we should increment the major version.
    Introducing breaking changes is fine as long as they are necessary for the health of the project/increase the usability of the project.

  • Now that I get write access, do you still prefer changes to go through PRs?
    Not for anything you don't need us to look over or are certain about. If it's a quality of life change that isn't a huge feature or major change, no need to make a PR when you have write access. (Bug fixes shouldn't need PRs either.)

  • Other things?
    We should have a development branch (or features branches if preferred), and avoid pushing to the main branch until the feature(s) in development is/are stable.
    Other than that, nothing comes to mind.

I'll be sure to write up a proper CONTRIBUTING.md when I get a chance. Thanks for the help!