document client product dev process

[zkat]

Fixes: #8994

Rendered

[karann-msft]

This also needs to address how release notes would work. Today we use this custom tool to generate release notes - https://github.com/NuGet/Entropy/tree/master/ChangelogGenerator in markdown and it is published to docs. For example - this page was generated using the ChangelogGenerator - https://docs.microsoft.com/en-us/nuget/release-notes/nuget-5.4. Also note the link at the bottom of the page.

[karann-msft]

Another way to think about an epic and should be documented in the guidance - if this is a customer-facing feature, it should be the parent of all tasks from spec'ing to writing the actual code to test to insertion to shipping and writing docs. The feature should have shipped and documented for the epic to be considered complete before being closed. At no point should there be more than one super-parent epic tracking an experience.

[zkat]

@karann-msft how do the new changes look? Did I capture this alright?

[nkolev92]

This looks amazing! :)

2 questions:

• Have we discussed how we would handle the transition yet?
• Once the process change is implemented, do you think this should be in the NuGet.Client docs folder? Well not this exactly, it'll be more of a doc describing the process we are following.

[zkat]

@nkolev92

Have we discussed how we would handle the transition yet?

I think this is probably part of what we'll be discussing in this week's team meeting.

Once the process change is implemented, do you think this should be in the NuGet.Client docs folder? Well not this exactly, it'll be more of a doc describing the process we are following.

I don't know! I think it should live in the same place that the Labels doc lives. Other than that, I have no opinion. I'll add it to my little agenda list for this week's meeting.

[nkolev92]

I meant to approve yesterday :)

[anangaur]

How are issues being worked upon linked to OKRs? Is there a mechanism to link these? I am fine without the linking if this causes more hassle than benefit :)

[anangaur]

May be an additional tag on Epic that differentiates from internal or random big chunk of work from customer facing features that we would to track on the Roadmap project?

[zkat]

What tag would you like? And would it be ok to let PM be in charge of adding it? :)

[anangaur]

I was thinking about having a label like Feature or anything else that suits this design. IMO, such an Epic should be assigned to PMs. And hence once we decide on the label, anybody including PMs can add them.

[nkolev92]

I feel like feature is an overloaded term :)
There are lots of things that are features and should be tracked as such, not just ones that need to part of the public roadmap.

I'd suggest something explicit...call it roadmap if the only purpose on the label is to indicate that the epic in question is part of the roadmap.

[karann-msft]

What's an example of a feature that wouldn't be on the public roadmap?

[nkolev92]

If we look at https://github.com/NuGet/home/issues?q=is%3Aopen+is%3Aissue+label%3AType%3AFeature for example.

There are 200+ issues labeled as Type:Feature. Now if we review those, probably not all of those are truly features.

Some of these are engineering features that affect a few people, but are still from a product perspective features. They are a significant, additive part of the product.
#8719 In this case, the product is our library.
#7917 Product is msbuild, few people would use it, but useful.
#7709

I feel like adding all these in the public roadmap, might introduce visual overload.
Finally, there are certain bug fixes that deserve to be part of the public roadmap as well :) The Task Cancelled work is one that I can remember.

[zkat]

@anangaur

How are issues being worked upon linked to OKRs? Is there a mechanism to link these? I am fine without the linking if this causes more hassle than benefit :)

That's documented here: https://github.com/NuGet/Home/pull/9050/files#diff-a7998e60809a6bfe02c8b9ac375cc676R18-R24