Add [compat-breaking] and [preview-breaking] labels to issues/PRs that would be #1571
Comments
|
Haha... I totally misunderstood you @benaadams, I thought you had said in aspnet/Mvc#4842 (comment) that @Eilon had added this but you did indeed edit it to reflect the proper pronoun "I". :) In any case, it is made and I am grateful. I guess I could have added this, but honestly I feel like I am being a thorn in everyone's side here and I don't think it would get much traction. Regardless, I will provide my thoughts as this to me does seem like a significant problem not just here with ASP.NET but MSFT in general. Basically, the fundamental issue here is that there is too much surface area for information, and unless you have ALL of it covered, you are bound to miss information. Here is a quick inventory of all the ways that information is disseminated by MSFT and accessed by their customers:
Pick your poison, right? MSDN blogs are compounded by the fact that the commenting system is baked in 2005 via a very poorly implemented Wordpress blog. Its formatting is terrible, leading to very constrained and unfriendly threads as more people post, or a person makes more posts (who me? 👼 👼 👼). Here is a great example (commentfest courtesy of yours truly 👼 👼 👼 ) I have on more than one occasion thought of making an app that sort of wrangles all these data points and makes it easier so that MSFT has better interaction with its developers, and developers have a better grasp/handle on what is going on. However, in doing so it would ultimately have me touching HTML5/JS and we cannot have that now, can we? ;) Anyways, just wanted to throw that out there. Speaking more practically/pragmatically, we are sort of limited at present by GitHub's features, which are great in a lot of ways, but not so great in others, and we are running into this limitation here. For instance, it would be great to extend GitHub to provide a workflow that accomplishes the goals that we are looking to achieve. The other option is maybe incorporating another 3rd party application/service that might assist, but that would also add yet another item to the identified list above. |
|
@Mike-EEE I know what you mean, for example, I used to keep up with every development in the Azure space; but MS are now moving at such a furious pace I think it would require several full time jobs to be able to do that alone. Aspnet and dotnet are moving at a similar pace and from strength to strength. Most changes are "value add"; if you know about them its a bonus, if you don't its not a problem and its also great to see. However, it would be helpful to highlight potential changes that are breaking at earlier inception from the general maelstrom of activity. |
|
Yeah there is a general problem of developer engagement/interaction and then there is the here and now with what is being experienced here. Speaking to the one thing that GitHub does really well: those reactions. At a glance I could tell and knew before I wrote a dissenting word that I was not on the majority side. It's really nice to see and it is also very valuable and useful for stakeholders. The same could be said for UserVoice and its vote totals. I think words get in the way (something that GitHub doesn't do well is conversations and their resulting threads). It's really all about capturing sentiment first and foremost, and then using words to hash out the details/considerations. But yes... lots going here for the push to RTM. Bigger fish to fry, but I am super appreciative of the capture. 👍 |
|
I think there really needs to be a separate "Announcements" one that is "Requesting Feedback". I would say almost every breaking change should go from Issue -> Feedback -> Announce I wholly support JSON being camelCased by default but I substantially disagree with how this was achieved. If I would have been able to provide feedback, the impact of this could have been widely mitigated (or ignored and no difference than today, but i never had the opportunity). For changes that are backwards compatible, there doesn't specifically need to be calls for feedback. For large changes it would be beneficial, but many items would be fine to short circuit going straight from code merged to announced. @benaadams "but MS are now moving at such a furious pace I think it would require several full time jobs to be able to do that alone." then Microsoft should hire as many as necessary to achieve that (or transition nokia folks etc) |
|
@dotnetchris in my experience almost everything whether breaking or not currently has two feedback steps and follows the path of
The Issues may not pass the Feedback step and the PRs also may not pass the Feedback step, both being closed at that either stage. Some merges don't have issues, and some don't have PRs, like build break fixes from upstream changes and security patches; but they are generally rare. Breaking changes if they make it to Merge add the However, there are an enormous number of issues and PRs across the aspnet and dotnet repos. This suggestion would be to add a new tag on the Issues when raised and the related PRs when created to highlight the breaking ones; whether they are community raised or not; and whether they are expected to be taken further or not. Essentially changes that would have a wider "cost" that is not captured within the change description itself. However, being alerted to them earlier would be a much larger volume than what happens in announcements. Equally what breaking changes are relevant or important to one person or not would be the same to another so I think a "Requesting Feedback" channel for these would probably just be noisy and busy work? |
|
One question for folks here is this: what exactly are you looking to be labelled as "breaking"?
|
|
@Eilon that's a really hard question you ended with because semantic versioning has never been followed. But the scenario of person updates their existing project, and every single one of their apis is broken? That would be a clear example of what needs a tons of eye balls on. Going back to the amount of noise generated. I feel like anything that's important enough to show up on announcements when it's complete would have been important enough to show up in the "give us feedback" radiator. The more i speak of this, it sounds like the announcements radiator itself might be the best usage. Getting an initial feedback announcement, then several weeks or months later the launched announcement. That would double the amount of items heading into the announcements, but if the change is exactly from 1 item to 2 items, I don't see that being the straw that breaks the camel's back. If it multiplied from say the 1 announcement today to 8x, 16x, or more, that would likely lead to mass unsubscribe. |
|
@dotnetchris by our interpretation, semantic versioning allows arbitrary changes in pre-release products. The only compatibility rules are ones that apply for major, minor, and patch releases. This product is still in pre-release, so we have made breaking changes across builds and that fits within the rules of semantic versioning. If we have misinterpreted semantic versioning, please let us know. |
|
Definitely not 3; if someone is living that close to the edge they should either accept breaks, or be paying closer attention to the repo in question. Also its at a stage where such changes can equally be reversed and with changes often being more exploratory in nature. Currently/Historically 2 Going forward definitely 1, but I imagine such breaks will be limited and people will still want to be trying new features so still 2? However in that light, maybe two labels then? Something like [compat-breaking] and [preview-breaking]? |
|
Are breaking changes an issue after RTM? Going out to the uninformed public for feedback on every feature seems like a good way to create a lot of low quality discussion and bikeshedding. I wouldn't do it but y'all have a lot more resources to find the good points in the noise. |
|
Perhaps they are uninformed at present @JamesNK, but by providing them more opportunity to become more involved in the process, they become more informed, maybe even helpful. Yes, It will involve more chatter, but the idea (in my view -- and/or from a stakeholder/overview/product manager perspective) is to capture aggregate/overall sentiment and not every detail. So yeah, resources to build this sort of cool engagement/sentiment application/service/workflow would be nice and a good start. 😄 |
|
@JamesNK at a guess Type 1 [compat-breaking] issues post RTM would likely be items raised from the community without a full understanding of the impacts or ramification of the changes. |
|
It's exactly what I'm afraid will happen. Lots of meaningless discussion with lots of sideline coach on how thing should be. Also, more time for the team to go through those instead of just, you know, deliver. I hope we can have those discussions but I'm afraid the community is just going to ruin it. |
|
Not suggesting any additional feedback beyond what github already provides or a [new feature] tag where there would be a lot of bike shedding (which may be good, may be bad). Increasing the visibility of compat-breaks; which will directly effect people anyway, at an earlier stage may make people feel more involved, feel there was more notice and openness and diffuse some of the community push-back that can happen at announcements. Either through incorporating feedback; understanding of why the changes are needed or just an earlier awareness of the changes. I'm sure dealing with some of the fallout from announcements can be equally time consuming as well as disheartening to the team and the community - so it would be good to come up with a way to address that. |
|
Haha... I forgot I had even made a vote around my central rant/concern/anxiety, but I did and it was flagged as Under Review with only my initial 3 votes to the tally. Guess it is already on the radar. :P |
benaadams
changed the title
|
FYI/FWIW, looks like there is a new effort afoot to assist feedback between Visual Studio and its users. This looks like it replaces (at least) UserVoice and Connnect in one offering. Perhaps it can ultimately be extended to other products/services as well: Pretty cool stuff, Team MSFT! |
|
Hi all, I just updated the engineering guidelines with info on breaking changes in major versions: https://github.com/aspnet/Home/wiki/Engineering-guidelines#breaking-changes This is roughly inline with the suggestions listed in this issue for major breaking changes. |
* Fixed regression caused by transport refactoring - Libuv should not close the socket until it has started it. Before this was enforced by calling ReadStart before starting the frame but the flow has changed. Now that closing the connection is communicated via the pipe, we need to start consuming writes after calling ReadStart. - Renamed OnSocketClosed to Close and moved dispose and logging into that method. Fixes #1571
ghost
locked as resolved and limited conversation to collaborators
There has been a lot of community friction around announcement items coming as a "surprise" although they have been issues or PRs prior to that where discussion has taken place.
A recent example would be the announcement aspnet/Announcements#194 and discussion about it aspnet/Mvc#4842 with its 3 month earlier related issue aspnet/Mvc#4283 though there are many others.
One of the issues is aspnet as a whole is a very fast moving project so people generally only subscribe to announcements rather than every repo; thus items can come as a surprise.
It is also hard to spot breaking change issues/PRs prior to them merged and implemented and becoming announcements.
If a "breaking" label was added to such issues/PRs it would be easier for people to spot these kinds of changes at an earlier stage and feel less surprised or be able to participate at an earlier stage, hear other points of view etc.
It would still require proactive looking, but it wouldn't be too hard to create a filter+aggregator to bring these into one place across repos (either by a community member or otherwise)
The text was updated successfully, but these errors were encountered: