-
Notifications
You must be signed in to change notification settings - Fork 564
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
Supported scenarios table. #530
Conversation
Looking good so far!
|
Do GitHub emoji's work? How about ✅ 🚧 and ❌ ? I think we would need to get permission to make the Win10 emojis OSS. |
![Image](http://findicons.com/files/icons/573/must_have/16/add.png) -- Not Yet Supported: Future release | ||
|
||
![Image](http://findicons.com/files/icons/573/must_have/16/delete.png) -- Not Supported: Will not support | ||
|
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.
Hmmm -- I think a "will not support" scenario belongs in a different table. Otherwise we will always have tables with red X's and make the product look incomplete. And I think something like the red X is the right icon for "Not yet supported". Ideally the table will contain only "supported", "not yet tested", and "not yet supported".
Out of curiosity, it is possible to make the "not yet supported" items also contain a link to an issue? Or does that blow out the size of the columns?
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 it possible that something we do support in UWP and Windows might not be able to be supported in Linux or Mac, if so then that is the scenario for needing a "Will not/Cannot Support".
Links are easy, from what I saw it didn't screw up the formatting. I was thinking that if we had an issue label for each scenario then we might be able to include a link to an issue query that would only show issues related to that scenario.
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.
You're right -- if something will never be supported in UWP or Linux, I guess we need an icon for that. I was thinking only about having solid rows of "will not support" looking bad. Maybe it should be something less alarming looking -- like N/A. Thoughts?
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.
Currently we don't have anything that we intentionally only support for one platform but not another, so I think we don't need the "will not support" icon for now. We can add it when we actually need it in the future.
Conceptually, anything that is not covered by any rows of the table is not supported. I agree we should avoid any solid rows of "will not support".
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 agree we don't need a "will not support" icon for now. I think "not supported" plus a link to an issue is sufficient (where the issue might explain why it is not supported now or that there are no plans to support it)
I also believe we have (and will have more) WCF features that we find do not work on some platform because our dependent packages don't support it. Examples: NegotiateStream in NET Native, or using the X509Store in certain Linux distros. I think having a single "not supported" icon is sufficient to cover this case, as long as it has a link to explain why it is not supported.
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 think it would be a good convention that any icon other than "supported" should have a hyperlink the user can follow for more information. It might be a link to an issue or a markdown file. I think we should also adopt a simple naming convention for the hyperlink's display name. Something simple like "?" or "why?". As a user, I think the first thing I would want to know about a "not supported" item is "why not?" and "when?"
We can get the basic table checked in and fill in the hyperlinks afterwards (though maybe one hyperlink on the initial checkin would help show the pattern to follow.
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.
We discussed links to Issues or Issue queries that correlate to each scenario, maybe we can add labels to connect Issues to the scenarios.
It also occurred to me we should probably make a folder under documentation called "releases" and then have a separate folder under each one for each release (ex: documentation/releases/rc1). We might add other md files to describe other aspects of that release. Let me study how other repo's are handling this and come back with a proposal. Don't block the merge on this decision -- we can move and rename anytime. |
I'm going to update the file removing the icons so I can just check-in the simple table I started, Ron can then edit it and add scenarios and emojis. |
0a75852
to
2ddd1e2
Compare
*First draft, handing off to Ron to flech out scenarios. *Using emojis insted of icons.
2ddd1e2
to
100dafe
Compare
Supported scenarios table.
LGTM. I'd say merge this now and I'll make a new PR with some proposed scenario rows. |
*First draft
*Images need to be put on our repo as well, other teams added an 'Image' folder under Documentation as well.
*Need to be careful of the license for the icons used, would love to use icons already being used by other MS projects on GitHub but couldn't find the image source for some used by Jenkins.
*Click on "Display the rich diff" to see it properly, if some image didn't load just refresh.