[Starlingx-discuss] Important! Storyboard Story Tag & Prefix Policy
I have made an executive decision as to how we should use the Storyboard tool. After discussing the matter with Ghada and our OpenStack Foundation team, I have documented our Tag and Prefix policy[0] on the wiki, in the section called "Story and Bug Tracking" [1]. I'm doing this because Reasons [2]. Here is a summary of the policy. All Stories in the Storyboard tool shall have Tags. If you create a new Story, make sure to add the tag "stx.new". We can then query this story and assign it to a sub-project and a release. If you don't tag it that way, we may never find it again. Assigning Stories to releases is a process that I think should be driven by the Cores together with the Release team. That is TBD. If you are filing a bug, please also add the "stx.bug" tag. I have updated all of the currently entered bugs with that tag. If you are filing a Story for a feature, please add the "stx.feature" tag. I'm going to update the existing feature stories to add that tag soon. I'd like to break down planning for the project into a set of Sub-projects. Each will have its own tag so the team working on that Sub-project can manage their work items. I'll be adding those tags soon as well. Should a team decide to add additional tags to Stories, for example so they can build a Board in Storyboard for their work, feel free, but please update the document on the wiki [0]. Note that as far as I can tell, each tag needs to be entered one at a time in the web UI. Brucej [0] https://wiki.openstack.org/wiki/StarlingX/Tags_and_Prefixes [1] https://wiki.openstack.org/wiki/StarlingX#Story_and_Bug_Tracking [2] We need to assign issues to sub-projects and releases, and keep track of bugs and features separately to simplify doing bug scrubs and release planning. Tags are easily searchable and don't clutter up the text fields. Using queries instead of Worklists or Boards gives us both flexibility and reliability.
Bruce, Do you have a pre-build query and can be shared with the team? For example, stx.bug.not_resolved? Stx.feature.merged? Thx. - cindy From: Jones, Bruce E [mailto:bruce.e.jones@intel.com] Sent: Saturday, July 21, 2018 3:07 AM To: starlingx-discuss@lists.starlingx.io Subject: [Starlingx-discuss] Important! Storyboard Story Tag & Prefix Policy I have made an executive decision as to how we should use the Storyboard tool. After discussing the matter with Ghada and our OpenStack Foundation team, I have documented our Tag and Prefix policy[0] on the wiki, in the section called "Story and Bug Tracking" [1]. I'm doing this because Reasons [2]. Here is a summary of the policy. All Stories in the Storyboard tool shall have Tags. If you create a new Story, make sure to add the tag "stx.new". We can then query this story and assign it to a sub-project and a release. If you don't tag it that way, we may never find it again. Assigning Stories to releases is a process that I think should be driven by the Cores together with the Release team. That is TBD. If you are filing a bug, please also add the "stx.bug" tag. I have updated all of the currently entered bugs with that tag. If you are filing a Story for a feature, please add the "stx.feature" tag. I'm going to update the existing feature stories to add that tag soon. I'd like to break down planning for the project into a set of Sub-projects. Each will have its own tag so the team working on that Sub-project can manage their work items. I'll be adding those tags soon as well. Should a team decide to add additional tags to Stories, for example so they can build a Board in Storyboard for their work, feel free, but please update the document on the wiki [0]. Note that as far as I can tell, each tag needs to be entered one at a time in the web UI. Brucej [0] https://wiki.openstack.org/wiki/StarlingX/Tags_and_Prefixes [1] https://wiki.openstack.org/wiki/StarlingX#Story_and_Bug_Tracking [2] We need to assign issues to sub-projects and releases, and keep track of bugs and features separately to simplify doing bug scrubs and release planning. Tags are easily searchable and don't clutter up the text fields. Using queries instead of Worklists or Boards gives us both flexibility and reliability.
There are links on the wiki page to pre-built queries under the Story and Bug Tracking section. The links look like this: https://storyboard.openstack.org/#!/story/list?status=active&project_group_id=86&tags=stx.bug. You can change the highlighted text to query for various things. I'm still learning how to do this. Ghada send me a script that shows what you can do if you know scripting: #!/bin/bash curl https://storyboard.openstack.org/api/v1/tasks?project_group_id=86|python -mjson.tool|grep -B11 "\"assignee_id\": null" |egrep "title|\<id\>|story_id" > unassigned_tasks.txt sed 's/,//g;/^$/d' unassigned_tasks.txt | paste - - - From: Xie, Cindy Sent: Sunday, July 22, 2018 5:33 PM To: Jones, Bruce E <bruce.e.jones@intel.com>; starlingx-discuss@lists.starlingx.io Subject: RE: [Starlingx-discuss] Important! Storyboard Story Tag & Prefix Policy Bruce, Do you have a pre-build query and can be shared with the team? For example, stx.bug.not_resolved? Stx.feature.merged? Thx. - cindy From: Jones, Bruce E [mailto:bruce.e.jones@intel.com] Sent: Saturday, July 21, 2018 3:07 AM To: starlingx-discuss@lists.starlingx.io<mailto:starlingx-discuss@lists.starlingx.io> Subject: [Starlingx-discuss] Important! Storyboard Story Tag & Prefix Policy I have made an executive decision as to how we should use the Storyboard tool. After discussing the matter with Ghada and our OpenStack Foundation team, I have documented our Tag and Prefix policy[0] on the wiki, in the section called "Story and Bug Tracking" [1]. I'm doing this because Reasons [2]. Here is a summary of the policy. All Stories in the Storyboard tool shall have Tags. If you create a new Story, make sure to add the tag "stx.new". We can then query this story and assign it to a sub-project and a release. If you don't tag it that way, we may never find it again. Assigning Stories to releases is a process that I think should be driven by the Cores together with the Release team. That is TBD. If you are filing a bug, please also add the "stx.bug" tag. I have updated all of the currently entered bugs with that tag. If you are filing a Story for a feature, please add the "stx.feature" tag. I'm going to update the existing feature stories to add that tag soon. I'd like to break down planning for the project into a set of Sub-projects. Each will have its own tag so the team working on that Sub-project can manage their work items. I'll be adding those tags soon as well. Should a team decide to add additional tags to Stories, for example so they can build a Board in Storyboard for their work, feel free, but please update the document on the wiki [0]. Note that as far as I can tell, each tag needs to be entered one at a time in the web UI. Brucej [0] https://wiki.openstack.org/wiki/StarlingX/Tags_and_Prefixes [1] https://wiki.openstack.org/wiki/StarlingX#Story_and_Bug_Tracking [2] We need to assign issues to sub-projects and releases, and keep track of bugs and features separately to simplify doing bug scrubs and release planning. Tags are easily searchable and don't clutter up the text fields. Using queries instead of Worklists or Boards gives us both flexibility and reliability.
FYI, the StoryBoard API documentation is available at: https://docs.openstack.org/infra/storyboard/webapi/v1.html# From: Jones, Bruce E [mailto:bruce.e.jones@intel.com] Sent: Sunday, July 22, 2018 9:25 PM To: Xie, Cindy; starlingx-discuss@lists.starlingx.io Subject: Re: [Starlingx-discuss] Important! Storyboard Story Tag & Prefix Policy There are links on the wiki page to pre-built queries under the Story and Bug Tracking section. The links look like this: https://storyboard.openstack.org/#!/story/list?status=active&project_group_id=86&tags=stx.bug. You can change the highlighted text to query for various things. I'm still learning how to do this. Ghada send me a script that shows what you can do if you know scripting: #!/bin/bash curl https://storyboard.openstack.org/api/v1/tasks?project_group_id=86|python -mjson.tool|grep -B11 "\"assignee_id\": null" |egrep "title|\<id\>|story_id" > unassigned_tasks.txt sed 's/,//g;/^$/d' unassigned_tasks.txt | paste - - - From: Xie, Cindy Sent: Sunday, July 22, 2018 5:33 PM To: Jones, Bruce E <bruce.e.jones@intel.com<mailto:bruce.e.jones@intel.com>>; starlingx-discuss@lists.starlingx.io<mailto:starlingx-discuss@lists.starlingx.io> Subject: RE: [Starlingx-discuss] Important! Storyboard Story Tag & Prefix Policy Bruce, Do you have a pre-build query and can be shared with the team? For example, stx.bug.not_resolved? Stx.feature.merged? Thx. - cindy From: Jones, Bruce E [mailto:bruce.e.jones@intel.com] Sent: Saturday, July 21, 2018 3:07 AM To: starlingx-discuss@lists.starlingx.io<mailto:starlingx-discuss@lists.starlingx.io> Subject: [Starlingx-discuss] Important! Storyboard Story Tag & Prefix Policy I have made an executive decision as to how we should use the Storyboard tool. After discussing the matter with Ghada and our OpenStack Foundation team, I have documented our Tag and Prefix policy[0] on the wiki, in the section called "Story and Bug Tracking" [1]. I'm doing this because Reasons [2]. Here is a summary of the policy. All Stories in the Storyboard tool shall have Tags. If you create a new Story, make sure to add the tag "stx.new". We can then query this story and assign it to a sub-project and a release. If you don't tag it that way, we may never find it again. Assigning Stories to releases is a process that I think should be driven by the Cores together with the Release team. That is TBD. If you are filing a bug, please also add the "stx.bug" tag. I have updated all of the currently entered bugs with that tag. If you are filing a Story for a feature, please add the "stx.feature" tag. I'm going to update the existing feature stories to add that tag soon. I'd like to break down planning for the project into a set of Sub-projects. Each will have its own tag so the team working on that Sub-project can manage their work items. I'll be adding those tags soon as well. Should a team decide to add additional tags to Stories, for example so they can build a Board in Storyboard for their work, feel free, but please update the document on the wiki [0]. Note that as far as I can tell, each tag needs to be entered one at a time in the web UI. Brucej [0] https://wiki.openstack.org/wiki/StarlingX/Tags_and_Prefixes [1] https://wiki.openstack.org/wiki/StarlingX#Story_and_Bug_Tracking [2] We need to assign issues to sub-projects and releases, and keep track of bugs and features separately to simplify doing bug scrubs and release planning. Tags are easily searchable and don't clutter up the text fields. Using queries instead of Worklists or Boards gives us both flexibility and reliability.
On 07/20/2018 01:07 PM, Jones, Bruce E wrote:
I have made an executive decision as to how we should use the Storyboard tool. After discussing the matter with Ghada and our OpenStack Foundation team, I have documented our Tag and Prefix policy[0] on the wiki, in the section called “Story and Bug Tracking” [1]. I’m doing this because Reasons [2].
Here is a summary of the policy.
All Stories in the Storyboard tool shall have Tags. *If you create a new Story,* *make sure to add the tag “stx.new”*. We can then query this story and assign it to a sub-project and a release. If you don’t tag it that way, we may never find it again. Assigning Stories to releases is a process that I think should be driven by the Cores together with the Release team. That is TBD.
Given that bugs might be opened by people that don't know our procedures, would it would maybe make more sense to have new bugs start with no such tag, and then we could add a tag indicating that it's been processed? We could create an automatic workist to track "Stories where ProjectGroup is starlingx and Tags is bug and Tags is not new" in order to monitor which new bugs need to get assigned a sub-project and release.
If you are filing a bug, please also add the “stx.bug” tag. I have updated all of the currently entered bugs with that tag. If you are filing a Story for a feature, please add the “stx.feature” tag. I’m going to update the existing feature stories to add that tag soon.
Why do we need "stx." prefixes for the tags? If it's to distinguish stories/tasks belonging to StarlingX I think we could skip the prefix and add a "ProjectGroup is starlingx" query clause when querying stories/tasks. Chris
Please see inline below due to my silly top posting email client. Chris, the main answer to your questions is that I don't know much about how Storyboard works, I'm learning new things every day. I'd like to get us on a more operational footing quickly so I'm working with what I know each day. We can easily make changes to any process as we learn more about how things really work. brucej -----Original Message----- From: Chris Friesen [mailto:chris.friesen@windriver.com] Sent: Monday, July 23, 2018 7:56 AM To: starlingx-discuss@lists.starlingx.io Subject: Re: [Starlingx-discuss] Important! Storyboard Story Tag & Prefix Policy On 07/20/2018 01:07 PM, Jones, Bruce E wrote:
I have made an executive decision as to how we should use the Storyboard tool. After discussing the matter with Ghada and our OpenStack Foundation team, I have documented our Tag and Prefix policy[0] on the wiki, in the section called “Story and Bug Tracking” [1]. I’m doing this because Reasons [2].
Here is a summary of the policy.
All Stories in the Storyboard tool shall have Tags. *If you create a new Story,* *make sure to add the tag “stx.new”*. We can then query this story and assign it to a sub-project and a release. If you don’t tag it that way, we may never find it again. Assigning Stories to releases is a process that I think should be driven by the Cores together with the Release team. That is TBD.
Given that bugs might be opened by people that don't know our procedures, would it would maybe make more sense to have new bugs start with no such tag, and then we could add a tag indicating that it's been processed? [brucej] Yes, this would make sense. At the time I didn't know how to find Stories with no tags, or get the tags displayed in the web UI. I still don't know how to do the former, other than to run complex scripts. And have no idea how to change the web UI (other than contributing code to it). We could create an automatic workist to track "Stories where ProjectGroup is starlingx and Tags is bug and Tags is not new" in order to monitor which new bugs need to get assigned a sub-project and release. [brucej] That would also make sense, but I haven't figured out how to build a query that says "tag == NULL".
If you are filing a bug, please also add the “stx.bug” tag. I have updated all of the currently entered bugs with that tag. If you are filing a Story for a feature, please add the “stx.feature” tag. I’m going to update the existing feature stories to add that tag soon.
Why do we need "stx." prefixes for the tags? If it's to distinguish stories/tasks belonging to StarlingX I think we could skip the prefix and add a "ProjectGroup is starlingx" query clause when querying stories/tasks. [brucej] I don't know enough about how tags work. If it's just a random text field with no namespace, great, we can do whatever we want. But I didn't want to pollute the namespace of the other projects and didn't get an answer to my IRC query on #storyboard, so I went with a safe approach. Chris _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
On 07/23/2018 10:39 AM, Jones, Bruce E wrote:
-----Original Message----- From: Chris Friesen [mailto:chris.friesen@windriver.com]
All Stories in the Storyboard tool shall have Tags. *If you create a new Story,* *make sure to add the tag “stx.new”*. We can then query this story and assign it to a sub-project and a release. If you don’t tag it that way, we may never find it again. Assigning Stories to releases is a process that I think should be driven by the Cores together with the Release team. That is TBD.
Given that bugs might be opened by people that don't know our procedures, would it would maybe make more sense to have new bugs start with no such tag, and then we could add a tag indicating that it's been processed?
[brucej] Yes, this would make sense. At the time I didn't know how to find Stories with no tags, or get the tags displayed in the web UI. I still don't know how to do the former, other than to run complex scripts. And have no idea how to change the web UI (other than contributing code to it).
Currently the only way I know of to find stories using OR and NOT clauses is to use automatic worklists. I plan on opening a storyboard bug to add more complex queries to the search mechanism.
We could create an automatic workist to track "Stories where ProjectGroup is starlingx and Tags is bug and Tags is not new" in order to monitor which new bugs need to get assigned a sub-project and release.
[brucej] That would also make sense, but I haven't figured out how to build a query that says "tag == NULL".
You can have arbitrary tags, so I don't think it makes sense to search for no tags at all. Specifically for finding stories that don't have a *specific* tag (or don't have one of a list of specific tags) you can create an automatic worklist, which then lets you do more complicated logic. It's a bit limiting in that you can only search for a series of "OR" statements, where each one is a series of AND clauses, where each clause is either matching or not matching. But like in my example you can make an automatic worklist for: "ProjectGroup is starlingx" AND "'bug' tag exists" AND "'triaged' tag doesn't exist" The above worklist is available at: https://storyboard.openstack.org/#!/worklist/420 In this scenario, we could set the "triaged" tag once the bug has been analyzed.
If you are filing a bug, please also add the “stx.bug” tag. I have updated As an example of tags, h all of the currently entered bugs with that tag. If you are filing a Story for a feature, please add the “stx.feature” tag. I’m going to update the existing feature stories to add that tag soon.
Why do we need "stx." prefixes for the tags? If it's to distinguish stories/tasks belonging to StarlingX I think we could skip the prefix and add a "ProjectGroup is starlingx" query clause when querying stories/tasks.
[brucej] I don't know enough about how tags work. If it's just a random text field with no namespace, great, we can do whatever we want. But I didn't want to pollute the namespace of the other projects and didn't get an answer to my IRC query on #storyboard, so I went with a safe approach.
As far as I can tell each tag just an arbitrary text string. When adding a tag you start typing and the system will give a drop-down list of all previously-specified tags containing the substring that you've typed so far, and you can pick one of them or add your custom string. When searching for stories/tasks you can start typing and it will show all ProjectGroups, Projects, and Tags containing the substring you've entered so far. Then you just pick the one you want. Here's an example of a bug from the vitrage project with multiple tags: https://storyboard.openstack.org/#!/story/2003065 Chris
On 07/23/2018 11:14 AM, Chris Friesen wrote:
But like in my example you can make an automatic worklist for:
"ProjectGroup is starlingx" AND "'bug' tag exists" AND "'triaged' tag doesn't exist"
The above worklist is available at: https://storyboard.openstack.org/#!/worklist/420
I've been informed that looking at someone else's public worklist doesn't let you see the query, sorry about that. Here are the steps generate the above worklist: 1) In "Create New" pulldown box at top, select "Worklist" 2) Add a title and select "automatic". 3) Under "Criteria", click in the box and type "starlingx" and click on the ProjectGroup. 4) Click the "+and" over on the right, click in the box and enter "bug" and select the tag from the provided list. 5) Click it the "+and" again, change the dropdown menu to "not matching", click in the box and enter "triaged" and select the tag from the provided list. 6) Click on "Save" to save the first line in the query. 7) Click on "Save" to save the worklist. In this example I'm envisioning someone adding the "triaged" tag once the initial vetting is done. This is just an example, similar queries could be used for other tags. Chris
participants (4)
-
Chris Friesen
-
Jones, Bruce E
-
Khalil, Ghada
-
Xie, Cindy