Skip to content
This repository was archived by the owner on Jul 15, 2023. It is now read-only.

Conversation

@SergeyTeplyakov
Copy link
Contributor

Fix for #64.

@hubuk, @sharwell: I would appreciate for the review.

@sharwell
Copy link
Contributor

I too would appreciate the review 😄

@sharwell
Copy link
Contributor

Looking at the issue list, I believe the project could benefit from two additional labels:

Label Meaning on Issue Meaning on Pull Request
erroneous contract The issue concerns an incorrect contract in the reference source code The issue concerns an incorrect contract in the reference source code
missing contract The issue concerns a missing contract in the reference source code The issue concerns a missing contract in the reference source code

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.

@aarondandy
Copy link
Contributor

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.

@sharwell
Copy link
Contributor

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.

@aarondandy
Copy link
Contributor

Requiring those tags will probably be important for generating release notes, which is another topic that may be important.

@sharwell
Copy link
Contributor

@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. 👍

@aarondandy
Copy link
Contributor

Good point, I think most of those "jump-in" sites that pop up can be configured to take different labels too

@SergeyTeplyakov
Copy link
Contributor Author

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
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also consider create chat room in gitter.im like corefx, roslyn, etc.

Copy link
Contributor

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.

Copy link
Contributor

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.

@hubuk
Copy link
Contributor

hubuk commented Jun 22, 2015

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):

Labels

This project uses many labels for categorizing issues and pull requests. Labels are grouped according to their category:

Label Meaning
0 - Backlog Issue not in the scope of the current milestone.
0 - Blocked Issue blocked by some external or internal dependencies.
1 - Ready Issue is ready to be fixed.
2 - Working Someone is currently working on the issue.
3 - Done Issue already addressed and a solution has been proposed.
Area: ccrewrite Issue related to Code Contracts rewriter.
Area: cccheck Issue related to Code Contracts static analyzer.
Area: ccdocgen Issue related to contracts documentation generator.
Area: ccrefgen Issue related to contract reference assemblies generator.
Area: contract Issue related to contracts for .Net Framework assemblies.
Area: installer Issue related to Code Contracts installer.
Area: editor extension Issue related to Code Contracts Editor Extension.
Area: property page Issue related to Visual Studio property pages for Code Contracts.
Area: documentation Issue related to product documentation.
ClosedAs: ByDesign The current behavior is by design and will not be changed.
ClosedAs: Duplicate Another issue contains a description of the same problem.
ClosedAs: Invalid The issue concerns a documented and correct behavior.
ClosedAs: Question The issue is a question for which an answer has been provided.
ClosedAs: Fixed The issue has been resolved.
Type: Bug The issue concerns a bug in the code.
Type: Enhancement The issue concerns an improvement to an existing functionality.
Type: Feature The issue concerns a completely new functionality to be implemented.

@SergeyTeplyakov
Copy link
Contributor Author

@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.
SergeyTeplyakov added a commit that referenced this pull request Jun 24, 2015
Add Contributing.md with a set of label descriptions.
@SergeyTeplyakov SergeyTeplyakov merged commit 2634865 into microsoft:master Jun 24, 2015
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants