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

[OTHER] Add CONTRIBUTING.md. #25

Open
brannonh opened this issue Sep 9, 2022 · 8 comments
Open

[OTHER] Add CONTRIBUTING.md. #25

brannonh opened this issue Sep 9, 2022 · 8 comments
Assignees
Labels
documentation Improvements or additions to documentation question Further information is requested
Milestone

Comments

@brannonh
Copy link
Collaborator

brannonh commented Sep 9, 2022

With multiple devs beginning to work on this project it would be good to set expectations and provide any necessary guidance via a CONTRIBUTING.md file.

We can discuss those expectations and guidance in this issue and track below what we want to include in the file. Feel free to 👍🏻 any ideas you like.

Expectations

Guidance

@brannonh brannonh added documentation Improvements or additions to documentation question Further information is requested labels Sep 9, 2022
@brannonh
Copy link
Collaborator Author

brannonh commented Sep 9, 2022

Per my comment in #14, I recommend that all development within this repo is done in separate branches, using some naming convention, and merged back into master. Merging should require PR review. PRs from forks could continue to function as normal.

@brannonh brannonh self-assigned this Sep 9, 2022
@Eforen
Copy link
Collaborator

Eforen commented Sep 9, 2022

I agree I think that we should have the convention for branchs should be Issue-####

@Eforen
Copy link
Collaborator

Eforen commented Sep 10, 2022

@brannonh and @jvanz if we are going to use PRs and branches to manage things and are going to have a rule that one of the 3 of us preforms a CR on it before merging it we need to make it a priority to address PRs as fast as reasonable and before other chores like maintaining documentation and replying to issues

@brannonh
Copy link
Collaborator Author

@brannonh and @jvanz if we are going to use PRs and branches to manage things and are going to have a rule that one of the 3 of us preforms a CR on it before merging it we need to make it a priority to address PRs as fast as reasonable and before other chores like maintaining documentation and replying to issues

@Eforen As much as I would like to be able to review PRs as soon as they are submitted, that is not my reality right now, nor do I think it's necessarily expected from an open source project. I want to see development move forward, but I can't respond to everything in real-time. I have other responsibilities and priorities in my life. I will get to things here as quickly as I can.

That being said, if we want to remove PR reviews from the process in favor of faster development, I don't have a problem with that.

@Eforen
Copy link
Collaborator

Eforen commented Sep 11, 2022

I think there is value in keeping the PRs in the process to at least have a paper trail. I am thinking it might make sense to atleast try to wait 24 hours for a posible CR. My main availablilty right now is the weekends so thats when I will likely be doing the most dev I do.

@brannonh brannonh added this to the 1.2.0 milestone Sep 16, 2022
@Eforen
Copy link
Collaborator

Eforen commented Apr 29, 2023

We do really need to do this

@brannonh
Copy link
Collaborator Author

Indeed. Been busy as of late, but will try to find some time to work on this project soon.

@Eforen
Copy link
Collaborator

Eforen commented May 17, 2023

Same I scraped together a release that people were asking for but have not had much time otherwise

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 question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants