-
Notifications
You must be signed in to change notification settings - Fork 602
Pull Request and Issue templates #705
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
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How do you envisage this behind useful?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Each code sample should have a test.
If any tests becomes flaky or simply broken, we should report a test failure just as we do for main hazelcast repo
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I feel like this might be over-engineered.
AFAIK we don't want test failures in GitHub for internal stuff, but do we really expect community users to address them? And do we expect the tests to be complicated enough to become flakey?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
do we really expect community users to address them
That's a very good "first time issue" stuff :)
do we expect the tests to be complicated enough to become flakey
Well I've encountered some tests that were flaky on MacOS (preferIPV4 FTW)
| Fixes INSERT_LINK_TO_THE_ISSUE_HERE | ||
|
|
||
| Checklist: | ||
| - [ ] Request reviewers if possible |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this for internal or external users? Isn’t this implicit?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Both, but mostly external
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just wondering how an external user would identify reviewers.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Git blame who wrote the test ;) GitHub already does that when you modify some files, it tells you who edited them before
|
I'm not a fan of these changes as it seems over-engineered. But then I think actually these are just copied from |
|
|
||
| Fixes INSERT_LINK_TO_THE_ISSUE_HERE | ||
|
|
||
| Checklist: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm wondering whether this should include documentation updates. If something's useful enough to prompt a new code sample, should it be in the docs too? What's the process for making that happen?
What do you think @oliverhowell ?
|
Some points are copied, some are new/adjusted to this repo. Idea is from core hazelcast indeed to guide people how to contribute by PRs and issues. |
No description provided.