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

updates language to be more open per #457 #458

Merged
merged 1 commit into from
Sep 1, 2019

Conversation

dgreene1
Copy link
Collaborator

fixes #457 by using language that clarifies that we are open to refactoring

fixes #457 by using language that clarifies that we are open to refactoring
@HoldYourWaffle
Copy link
Contributor

I'm just going for small iterative improvements here, perhaps something like this would be better?
(I know this is just "my writing preference", I just want the best for the project)

In situations where the code is very hard to extend, we may want to refactor or redesign certain aspects of the codebase. Such refactors should be proposed and agreed upon beforehand in the issue you created for your bugfix or feature proposal. While we strongly value enhancements to code quality, significant refactoring should usually be reserved for situations where the non-refactored version of code would be too difficult to work with.

Perhaps we should also mention something about the available time to review for maintainer(s)?

@dgreene1 dgreene1 merged commit affbb1e into master Sep 1, 2019
@dgreene1 dgreene1 deleted the 457-betterContributionGuidlineLanguage branch January 4, 2020 20:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Clarifying what "refactors for the sake of refactoring" means
2 participants