-
Notifications
You must be signed in to change notification settings - Fork 153
Add Contributing.md with a set of label descriptions. #68
Conversation
|
I too would appreciate the review 😄 |
|
Looking at the issue list, I believe the project could benefit from two additional labels:
The erroneous contract and missing contract labels are the equivalent of bug and enhancement respectively, and are used when talking about contracts for the reference source code. |
|
Part of me just wants one label for a contract change, mostly because a method may have a contract that allows all input and guarantees nothing for the input. Externally for users a method that previously had no preconditions which after an update has preconditions added will appear as a contract change. On the other hand I see benefit to the distinct labels as we don't have a good way to distinguish between a method that does not restrict input and another that was neglected. I also see the bug vs enhancement point of view but you could also apply two labels, one being contract-change and another being enhancement. |
|
I would feel comfortable with a contract issue (or similar), where in addition to that label we can apply bug if the code already has a contracts but the contract is incorrect, or enhancement if the update is simply an improved contract representing existing behavior. |
|
Requiring those tags will probably be important for generating release notes, which is another topic that may be important. |
|
@aarondandy The primary benefit I see to the contract tag is many contributors will feel comfortable updating reference contracts but might not feel comfortable editing the implementation. I want those users to have quick/easy access to our list of outstanding issues that they're more likely to be able to help with. 👍 |
|
Good point, I think most of those "jump-in" sites that pop up can be configured to take different labels too |
|
It seems that some general label would be very useful. But can we come up with more descriptive name? I mean 'contract' as a label sounds a bit weird for me. Maybe 'contract issue' or something similar? P.S. @sharwell I'll take a look at your PR, but I don't have experience with VSIX and other black magic that you've done in #66. |
CONTRIBUTING.md
Outdated
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.
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.
Eventually that will need to happen, but I'm not sure how #59 will impact it.
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.
create chat room
A few people here and here have been in https://jabbr.net/#/rooms/CodeContracts but most of the action is happening here in github issues.
|
I have proposed labels for NuGet as a starting point because they appear to be self explanatory. Assigned colors make them easy to read and understand what set of labels are possible on single issue. Having some explanation in project wiki or other document is also a good thing. So to utilize both ideas I come with the following proposition (source markdown available on my Wiki): LabelsThis project uses many labels for categorizing issues and pull requests. Labels are grouped according to their category:
|
|
@hubuk I don't think that we need so many different labels right now. I would like to stay with minimum number of labels and add them along the way when it would be obvious that wee need all of them. For instance, all this different labels per area would be useful only when we really would have tens of issues per each area. It could be true but could be not. The same is true for ClosedAs. Right now we have less issues than proposed labels. As I said, I would prefer evolve those labels based on real needs. Is it ok for you? |
…rts back initial state machine value that was used for getting method contract in async methods generated by Roslyn compiler. Add VS14RC compiler to the tools, added test that checks the fix by using Roslyn-based compiler. Add missing native dependencies for v4.5 compiler.
Add Contributing.md with a set of label descriptions.
Fix for #64.
@hubuk, @sharwell: I would appreciate for the review.