Skip to content

Conversation

@v-jigen
Copy link

@v-jigen v-jigen commented May 3, 2018

No description provided.

@msftclas
Copy link

msftclas commented May 3, 2018

CLA assistant check
Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.

❌ v-jigen sign now
You have signed the CLA already but the status is still pending? Let us recheck it.

@bpm-ms bpm-ms self-requested a review May 14, 2018 22:03
Copy link
Contributor

@bpm-ms bpm-ms left a comment

Choose a reason for hiding this comment

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

In general I think there's fundamentally a disagreement in approach here. I think labels should be used to describe and classify an issue. This document seems to mix that with the project management aspect. I think we should look into something like Github Projects, ZenHub, or Waffle for tracking progress / doing project management. I also think we don't necessarily need all the granularity of "in-progress' "in-design" "understood" etc. Most projects are content with "Not started", "In Progress", "done". I also think for the majority of issues that come in, adding all these labels is needless overhead.

@@ -0,0 +1,222 @@
Proposed labels by section on GitHub
Copy link
Contributor

Choose a reason for hiding this comment

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

I don't think this fits as the title of this document.

Assignees
---------------------------------------------------------------

> No labels for this section - just use the alias of the individuals owning the issue. MS alias showing is preferred.
Copy link
Contributor

Choose a reason for hiding this comment

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

github aliases should and need to be used. For PM purposes you can figure out behind the scenes the mapping

Labels
------------------------------------------------------------

> It is understood that some teams will have their OWN GItHub page. Focus is on the SF page and we can build on/modify for other Team GitHub pages later once the initial model is completed.
Copy link
Contributor

Choose a reason for hiding this comment

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

nit: GItHub -> GitHub
nit: OWN -> own


- All tags and labels are lower-case and dash separated

- All hierarchy is whack separated and no caps.
Copy link
Contributor

Choose a reason for hiding this comment

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

I think whack is technically backslash 😆, maybe say "forward slash" or /


| ***State/Status*** | ***Area*** | ***Issue Type*** | ***Pri*** |
|--------------------|--------------------------|------------------|-----------------|
| investigating | area-common | question | Pri-0,(regular) |
Copy link
Contributor

Choose a reason for hiding this comment

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

what does (regular) mean?

>
> **Important! The Bug or Enhancement will remain un-assigned until someone is ready to pick up the work!** We do not want to just assign items to people who have work already since it is possible others may want to contribute to the fix/feature.
>
> At the very least the issue can be assigned a future Milestone if it is understood that is where the work needs to be done **OR** if there is not a clear path for the bug, leaving the Milestone blank functions as a backlog for issues without a release assigned. Once it reaches the current Milestone, the additional labels may be added.
Copy link
Contributor

Choose a reason for hiding this comment

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

nit: or

>
> ***'Optional' Phases will apply to issues that are immediately understood allowing them to bypass many of the phases, moving the bug right to 'in-progress'.***

****Enhancement Issues****
Copy link
Contributor

Choose a reason for hiding this comment

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

you seem to have this on here twice?

| **Contributors**: | Community members that make any contribution to the project, whether it’s submitting code, fixing or reporting bugs, writing docs, etc.|
| **Users:** | General users who have a need for the project.|

> **As a measurement** we want to try and touch all new items within 48 hours. This is not exposed to the customer but is a metric for us to determine how quickly we are touching new issues. We need to ensure that feature area owners are actively triaging their issues and keeping them up to date.
Copy link
Contributor

Choose a reason for hiding this comment

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

This document is on public github, so yes it is exposed to the customer. Also, while there will be "customers" using the product, there are also "contributors" who are helping build the product. We should be considerate to not call everyone who is filing issues a "customer" because they may very well be a contributor who wants to be part of the development community and work on service fabric, as opposed to just using service fabric.

>
> A defined group of individuals consisting of Area Leads or Developers will be responsible for reviewing all new items.
>
> Once a new item has arrived the defined resource for 'touching' these issues for the first time will set the label 'triage' to the issue so that it can be reviewed.
Copy link
Contributor

Choose a reason for hiding this comment

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

"defined resource for 'touching' these issues" sounds really weird. Maybe find a word for that?

>
> Once all work is completed and signed off on, we can RTW and close-down the Milestone and move any remaining items into the appropriate/next Milestone.

Work Flow Process Table (Same as above - fewer words)
Copy link
Contributor

Choose a reason for hiding this comment

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

If these say the same thing, lets use the one with fewer words. That makes us have less copies to maintain and update as we change.

@samedder
Copy link
Collaborator

@bpm-ms I added my edits, let me know if this seems better. I removed the entire last section with a bunch of workflows I think that made the document too complicated.

ammarZaidi pushed a commit to ammarZaidi/service-fabric that referenced this pull request Sep 25, 2018
* Fix the logics to check if the object is serializable.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants