Skip to content
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

document client product dev process #9050

Open
wants to merge 4 commits into
base: dev
from
Open

document client product dev process #9050

wants to merge 4 commits into from

Conversation

@zkat
Copy link

zkat commented Jan 11, 2020

Fixes: #8994

Rendered

Fixes: #8994
@karann-msft

This comment has been minimized.

Copy link
Contributor

karann-msft commented Jan 14, 2020

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

This comment has been minimized.

Copy link
Contributor

karann-msft commented Jan 14, 2020

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

This comment has been minimized.

Copy link
Author

zkat commented Jan 14, 2020

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

@zkat zkat force-pushed the dev-zkat-client-dev-process branch from d6865b5 to f3058e0 Jan 14, 2020
Copy link
Member

nkolev92 left a comment

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.
designs/ClientDevProcess.md Show resolved Hide resolved
designs/ClientDevProcess.md Show resolved Hide resolved
designs/ClientDevProcess.md Show resolved Hide resolved
designs/ClientDevProcess.md Show resolved Hide resolved
@zkat

This comment has been minimized.

Copy link
Author

zkat commented Jan 15, 2020

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

Copy link
Member

nkolev92 left a comment

I meant to approve yesterday :)

Copy link
Member

anangaur left a comment

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

Concretely, these are GitHub issues tagged as Epic, and they navigate the board slightly different from regular issues:

1. When any issue under an Epic is In Progress, the associated Epic should be moved to the In Progress pipeline as well.
2. Epics should remain under "In Review" or "Validating" until the related change is available to customers. That is, they shouldn't be closed until released.

This comment has been minimized.

Copy link
@anangaur

anangaur Jan 15, 2020

Member

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?

This comment has been minimized.

Copy link
@zkat

zkat Jan 15, 2020

Author

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

This comment has been minimized.

Copy link
@anangaur

anangaur Jan 15, 2020

Member

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.

This comment has been minimized.

Copy link
@nkolev92

nkolev92 Jan 15, 2020

Member

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.

This comment has been minimized.

Copy link
@karann-msft

karann-msft Jan 16, 2020

Contributor

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

This comment has been minimized.

Copy link
@nkolev92

nkolev92 Jan 16, 2020

Member

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.

designs/ClientDevProcess.md Show resolved Hide resolved
@zkat

This comment has been minimized.

Copy link
Author

zkat commented Jan 15, 2020

@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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.