Storyboard Needs and Alternatives
Hello,
There have apparently been disparate discussions among different projects on whether or not they want to continue using Storyboard and what alternatives they should consider. Having these discussion is healthy, but I think we should try to have them in the open with a broad audience to ensure we've considered all the various moving parts involved. I'll do my best to kick start that discussion here in this thread.
The Problem(s) * Storyboard is slow. * Storyboard's deployment is aging and needs to be updated. * Storyboard is largely unmaintained at this point. * Web crawlers/indexers struggle to index Storyboard content because it is rendered client side via API calls.
These first two problems are related. There are apparently fixes for known performance issues and other long-standing bugs that have yet to be deployed as we need to update the deployment platform to a newer version of python.
Options * Update the Storyboard deployment and see if that improves things enough to make people happy. * Migrate projects onto one or more different issue trackers.
The first option would almost certainly need someone to step up and help out. But before we do that it is probably worthwhile to solicit feedback indicating people would want to continue to use storyboard if its performance and other usability issues are addressed.
The second option opens us to a tremendous number of different possibilities. Launchpad, Gitea, GitHub, Bugzilla, Trac, Redmine, etc. I think for this discussion to be productive we should avoid digging too deeply into these options now. And instead determine if Storyboard is something that we as a community want to try and keep alive. Once we've answered that question we can shift gears to this option if necessary.
We would love to hear your feedback. Additional user issues with storyboard, interest in updating/maintaining Storyboard (or the opposite), and thoughts on whether or not addressing known problems with the service would be sufficient to make people want to keep using it are all helpful.
The goal here isn't to try and convince anyone they should use Storyboard. Instead we're trying to understand if there are those that would like to keep using Storyboard, and if so, what effort would be necessary to make that possible. Once we've sorted this out we can have a followup discussion on what would be necessary to support projects that don't want to use Storyboard any longer.
Clark
On Tue, 2022-10-25 at 10:19 -0700, Clark Boylan wrote:
Hello,
There have apparently been disparate discussions among different projects on whether or not they want to continue using Storyboard and what alternatives they should consider. Having these discussion is healthy, but I think we should try to have them in the open with a broad audience to ensure we've considered all the various moving parts involved. I'll do my best to kick start that discussion here in this thread.
The Problem(s) * Storyboard is slow. * Storyboard's deployment is aging and needs to be updated. * Storyboard is largely unmaintained at this point. * Web crawlers/indexers struggle to index Storyboard content because it is rendered client side via API calls.
These first two problems are related. There are apparently fixes for known performance issues and other long-standing bugs that have yet to be deployed as we need to update the deployment platform to a newer version of python.
Options * Update the Storyboard deployment and see if that improves things enough to make people happy. * Migrate projects onto one or more different issue trackers.
The first option would almost certainly need someone to step up and help out. But before we do that it is probably worthwhile to solicit feedback indicating people would want to continue to use storyboard if its performance and other usability issues are addressed.
The second option opens us to a tremendous number of different possibilities. Launchpad, Gitea, GitHub, Bugzilla, Trac, Redmine, etc. I think for this discussion to be productive we should avoid digging too deeply into these options now. And instead determine if Storyboard is something that we as a community want to try and keep alive. Once we've answered that question we can shift gears to this option if necessary.
at least in the nova room several of use but not all express intreest in movign away form storyborad entirly. we were going to default back to lanuchpad to use a singel tool for all compute team deliverables and since nova is in lanuchpad and we dont have pland to ever change that we wanted to move placment to launchpad too.
even if the performance, ux and indexing issues were adress i woudl still prefer to consolidate on tooling.
We would love to hear your feedback. Additional user issues with storyboard, interest in updating/maintaining Storyboard (or the opposite), and thoughts on whether or not addressing known problems with the service would be sufficient to make people want to keep using it are all helpful.
The goal here isn't to try and convince anyone they should use Storyboard. Instead we're trying to understand if there are those that would like to keep using Storyboard, and if so, what effort would be necessary to make that possible. Once we've sorted this out we can have a followup discussion on what would be necessary to support projects that don't want to use Storyboard any longer.
ack. personlly i was proposing just closing the storybord project for placment and not porting anything since we largly have not touch it in 4 cycles. as such i think resetting our backlog by not porting anything was more useful since clearly we are unlike to fix any of them if we have not worked on tehm in 2+ years. im not tied to useing launchpad if there was a better alternitive i woudl not be agaisnt suing it but storyboard in its currnt form would be a regresstion based on our currnt usage so i dont see us adopting sotryboard for the other compute team deliverable. if other optiosn like gitea ectra are expored we woudl evaualate those at that point for now launchpad works for our needs in general.
Clark
On 10/25/22 10:19, Clark Boylan wrote:
Hello,
There have apparently been disparate discussions among different projects on whether or not they want to continue using Storyboard and what alternatives they should consider. Having these discussion is healthy, but I think we should try to have them in the open with a broad audience to ensure we've considered all the various moving parts involved. I'll do my best to kick start that discussion here in this thread.
The Problem(s) * Storyboard is slow. * Storyboard's deployment is aging and needs to be updated. * Storyboard is largely unmaintained at this point. * Web crawlers/indexers struggle to index Storyboard content because it is rendered client side via API calls.
These first two problems are related. There are apparently fixes for known performance issues and other long-standing bugs that have yet to be deployed as we need to update the deployment platform to a newer version of python.
Options * Update the Storyboard deployment and see if that improves things enough to make people happy. * Migrate projects onto one or more different issue trackers.
The first option would almost certainly need someone to step up and help out. But before we do that it is probably worthwhile to solicit feedback indicating people would want to continue to use storyboard if its performance and other usability issues are addressed.
The second option opens us to a tremendous number of different possibilities. Launchpad, Gitea, GitHub, Bugzilla, Trac, Redmine, etc. I think for this discussion to be productive we should avoid digging too deeply into these options now. And instead determine if Storyboard is something that we as a community want to try and keep alive. Once we've answered that question we can shift gears to this option if necessary.
We would love to hear your feedback. Additional user issues with storyboard, interest in updating/maintaining Storyboard (or the opposite), and thoughts on whether or not addressing known problems with the service would be sufficient to make people want to keep using it are all helpful.
As Sean mentioned, as a team (nova) we are going to discontinue use of storyboard for the placement project and start using launchpad again to make things consistent between nova and placement.
Launchpad also works well for tracking bug fix backports because you can "target to series" a single bug to add older releases to it. Backport patches get automatically posted on launchpad by the infra tooling without the need to create a new Task for each backport and adjusting the commit message of the backport to reference that Task.
That aside, I can share a little feedback about storyboard based on my experience using it for placement and openstackclient.
It might boil down to the first problem you listed "storyboard is slow" but I have found the search function to be unusable. A frequent workflow for me is to search for existing bugs in a project based on a keyword in the title, summary, or comments. With storyboard I haven't been able to succeed in doing that. From what I understand, you are supposed to be able to scope the search by project:<name> but the search will not accept it unless you choose it from the dropdown box that is supposed to appear. The dropdown populates extremely slowly or sometimes not at all. I realize I can just go to a project and choose to show 1000 items per page and use the browser search on the titles instead, but that won't help for keywords in the summary or comments.
Storyboard also isn't _as_ easy for the aforementioned patch backporting that happens constantly in nova. We could add a Task per older release to a Story and adjust the backport patch commit messages to reference the matching Tasks (this is essentially what I have to do downstream and it can be tedious 😇). Not a huge deal but in comparison not as easy as launchpad.
Other than that, I don't have any issues with storyboard. It's just because I use search functions so often in bug trackers in general, it happens to be not so usable for me overall.
The goal here isn't to try and convince anyone they should use Storyboard. Instead we're trying to understand if there are those that would like to keep using Storyboard, and if so, what effort would be necessary to make that possible. Once we've sorted this out we can have a followup discussion on what would be necessary to support projects that don't want to use Storyboard any longer.
Clark
On Tue, 2022-10-25 at 14:29 -0700, melanie witt wrote:
On 10/25/22 10:19, Clark Boylan wrote:
Hello,
There have apparently been disparate discussions among different projects on whether or not they want to continue using Storyboard and what alternatives they should consider. Having these discussion is healthy, but I think we should try to have them in the open with a broad audience to ensure we've considered all the various moving parts involved. I'll do my best to kick start that discussion here in this thread.
The Problem(s) * Storyboard is slow. * Storyboard's deployment is aging and needs to be updated. * Storyboard is largely unmaintained at this point. * Web crawlers/indexers struggle to index Storyboard content because it is rendered client side via API calls.
These first two problems are related. There are apparently fixes for known performance issues and other long-standing bugs that have yet to be deployed as we need to update the deployment platform to a newer version of python.
Options * Update the Storyboard deployment and see if that improves things enough to make people happy. * Migrate projects onto one or more different issue trackers.
The first option would almost certainly need someone to step up and help out. But before we do that it is probably worthwhile to solicit feedback indicating people would want to continue to use storyboard if its performance and other usability issues are addressed.
The second option opens us to a tremendous number of different possibilities. Launchpad, Gitea, GitHub, Bugzilla, Trac, Redmine, etc. I think for this discussion to be productive we should avoid digging too deeply into these options now. And instead determine if Storyboard is something that we as a community want to try and keep alive. Once we've answered that question we can shift gears to this option if necessary.
We would love to hear your feedback. Additional user issues with storyboard, interest in updating/maintaining Storyboard (or the opposite), and thoughts on whether or not addressing known problems with the service would be sufficient to make people want to keep using it are all helpful.
As Sean mentioned, as a team (nova) we are going to discontinue use of storyboard for the placement project and start using launchpad again to make things consistent between nova and placement.
Launchpad also works well for tracking bug fix backports because you can "target to series" a single bug to add older releases to it. Backport patches get automatically posted on launchpad by the infra tooling without the need to create a new Task for each backport and adjusting the commit message of the backport to reference that Task.
That aside, I can share a little feedback about storyboard based on my experience using it for placement and openstackclient.
It might boil down to the first problem you listed "storyboard is slow" but I have found the search function to be unusable. A frequent workflow for me is to search for existing bugs in a project based on a keyword in the title, summary, or comments. With storyboard I haven't been able to succeed in doing that. From what I understand, you are supposed to be able to scope the search by project:<name> but the search will not accept it unless you choose it from the dropdown box that is supposed to appear. The dropdown populates extremely slowly or sometimes not at all. I realize I can just go to a project and choose to show 1000 items per page and use the browser search on the titles instead, but that won't help for keywords in the summary or comments.
Storyboard also isn't _as_ easy for the aforementioned patch backporting that happens constantly in nova. We could add a Task per older release to a Story and adjust the backport patch commit messages to reference the matching Tasks (this is essentially what I have to do downstream and it can be tedious 😇). Not a huge deal but in comparison not as easy as launchpad.
Other than that, I don't have any issues with storyboard. It's just because I use search functions so often in bug trackers in general, it happens to be not so usable for me overall.
as a concreate example and to refersh my memory of using story board i tried to navagate to the placment project yesterday. to do that i searched for it in the projects tab as openstack/placement https://storyboard.openstack.org/#!/project/list?q=openstack%2Fplacement
as you can porbaly see its not in the list of results
if i just seach for placement https://storyboard.openstack.org/#!/project/list?q=placement its the last result with the title openstack/placement ...
if we click on that https://storyboard.openstack.org/#!/project/openstack/placement and say take the 3rd bug "Bug in placement conf file for Apache HTTPD" and seach for placement and HTTPD
https://storyboard.openstack.org/#!/search?q=placement%20HTTPD&title=pla...
its not in the lsit of results
if i use the full title https://storyboard.openstack.org/#!/search?q=Bug%20in%20placement%20conf%20f... also not there
however the popup that you get if you wait actully finds the story.
this UX makes story board feel like perl. you write it once and never read it again because you cant trivially find things using either the seach fucntionality or paging though the bugs. ile go to https://storyboard.openstack.org/#!/project/openstack/placement and set the limit to 100 or 1000 and using your broser to search.
i know it has some nice feature liek being ablt to create boards and worklist ectra to tag and track things bug the out of box or new user expeince is pretty bad if you dont actully go build better views in it as a tool.
for example and not picking on anyoen in particalar this board created by the monasca team https://storyboard.openstack.org/#!/board/190 looks pretty nice. its kanban inspired, clear to see and a arguablly niceer way visualise things the an etherpad for cordinating reviews but that isnt a day to day pain point for us in the same way fileing tasks for backports and updatign the commit message woudl be or searching for exising bugs.
there defintly are some nice design element to what storyboard was trying to enable but in its current hosted incarnation it makes our life harder not simpler.
if we as a comunity were to move to somethign other then storyboard and there was an objection to using launchpad then the 3 i would evauluate are github issues, gitea issues if we want to self host it or gihttps://storyboard.openstack.org/#!/story/2009315t-bug (https://github.com/MichaelMure/git-bug) the main blocker for gitia beside our current installtion not being designed to do it is the lack of Confidential bugs for security issues https://github.com/go-gitea/gitea/issues/3217 i assume sotryborad can do that but gitia and likely git-bug cant. we dont have to deal with a lot of secuity bug but its imporant that when we do we can use the same tool as regular bugs to track it so that its simple for people to correctly file secuiryt bugs.
the other issue si have with story boad that if address would make me more accpting with usign it is how you view/manage stories at the project level in your dashboard https://storyboard.openstack.org/#!/dashboard/stories you have this nice filter stories dropdown with check boxes however you cant filter on the subtask states of todo progres review invalid and merged. or on lables/tags. since everythign starts with a story that means both bugs and features are stories and since you cant filter on lables you cant filter in that view.
https://storyboard.openstack.org/#!/project/openstack/placement that is also true of the project view althought there its worse since the stories are displayed in tab base on active, meged and invalid state. those tabsl reload when you click on them so you also cant swithc beteen them simply. without the abilty to filter stories on tag/labes i cant get a bug or feature view without createing a borad myself. its extra fustrating since the tags are displayed on the page so i can clearlly see what ones are bugs or rfes but cant filter. i also cant find all stories that are "untriaged" since i cant display only the stories without tags.
i can almost get there with https://storyboard.openstack.org/#!/story/list?status=active&project_id=... that allows be to quickly filter to a proeject and look for a spcific tag, in this case placement and bug but i cant do "!= bug | != rfe" or find all stories without the "triaged" tag ectra so wee what are the new issues that as a bug triager i
while writing this reply i spend a littel tiem trying to create a boad to adress these issues and you can mostly hide some of them https://storyboard.openstack.org/#!/board/254 its simple to get all the untiraged issues, rfes adn bugs and group them. where you start hitting rough edges is when you want to dig deeper. storyboard allow syou to filter on storay status (merged invalid active) but that does not actully work properly. going back to the httpd bugs https://storyboard.openstack.org/#!/story/2009315 it has one task in todo and has the bug tag its in the all bug list bug does not show up in the bug backlog. the fixed bugs has 5 listed which is nice. what is not nice is if i look for stories in status merged for placment with the bug key its empty. i has to also seach for bugs with the fixed tag which has to be manulaly added.
so while at first glance it looks liek its easy to adress the isseus i raised jsut creating boards to provide the view you need when you try you hit roadblocks pretty quickly. the view also does not show tags or allow you to filter within the view
storyboad had a lot of potential and some nice features planned but the current install feels like a beta and not something that is ready for production use. it was mentioned this is an old verions. if the isntnace coudl be updated and some/all of these issues have been adress already then im not against trying it for another release but if noti really think its time to move on. its not form a lack of trying to use story borad that i dislike it. its form using it to try and find things.
i know this may come across overly negitive but i wanted to give feedback on the frustratiosn we have had so that if there are people that can work on adressing it we could continue to use it. in my day job i currently have to use downstream:(jira, bugzilla, trello) and upstream:(github issues, storyboard, launchpad) of those tools whiel storyboad is arguable better the bugzilla in every way excpte searching/grouping issues that alone makes it the hardest tool for me to use out of all of them. none of them are perferct and i can see why the story board team built it but it does not align well to projects that need to maintain and backport our code across multiple releases.
The goal here isn't to try and convince anyone they should use Storyboard. Instead we're trying to understand if there are those that would like to keep using Storyboard, and if so, what effort would be necessary to make that possible. Once we've sorted this out we can have a followup discussion on what would be necessary to support projects that don't want to use Storyboard any longer.
Clark
My few cents
In addition to all mentioned already I would like to add that I personally don’t feel UX intuitive. Even trying to work with it multiple times I am never really sure where do I need to click. Example from today - I want to add dependency in one story to another (in the same project) and I can’t find it. Maybe I want to close story as duplicate - I don’t know how.
Relatively often I try to have a look and process some issues (i.e. respond to the reporter) from mobile device. With storyboard this is not possible for me, it feels like a disaster. Having tasks inside single story can be mapped to task and subtask from some other issue tracker. It is all cool, but trying to have multiple tasks under story (https://storyboard.openstack.org/#!/story/2008619) also didn’t end up in being a success. It is good that task is automated to move to i.e. merged, but how to figure out later by which change? You can see on example of this story that event history is so long that you can’t do anything useful with it anymore.
I don’t want to continue listing issues. To answer the initial question - even assuming current issues of StoryBoard can be fixed I have issues using it (I tried multiple times and every time I am just frustrated). I don’t find this tool fulfilling task of being effective issue tracker. The fact that the software itself is barely maintained it is even more a sign for me this is not going to end good. I think most of us are having already enough of work to do not to waste time on something where better solutions (including open source) exist.
After trying to adapt existing tools to my processes and seeing how fast this becomes unusable I personally started with just relying only on most basic functionality (GitHub/Gitea/GitLab issues) without bells and whistles and am just fine - KISS
From all user-facing projects I am taking care of I place my “-1” to Storyboard. It should not only fit our dev processes, but be easy and intuitive to all users trying to report bugs.
Artem
On 26. Oct 2022, at 11:56, Sean Mooney smooney@redhat.com wrote:
On Tue, 2022-10-25 at 14:29 -0700, melanie witt wrote:
On 10/25/22 10:19, Clark Boylan wrote:
Hello,
There have apparently been disparate discussions among different projects on whether or not they want to continue using Storyboard and what alternatives they should consider. Having these discussion is healthy, but I think we should try to have them in the open with a broad audience to ensure we've considered all the various moving parts involved. I'll do my best to kick start that discussion here in this thread.
The Problem(s)
- Storyboard is slow.
- Storyboard's deployment is aging and needs to be updated.
- Storyboard is largely unmaintained at this point.
- Web crawlers/indexers struggle to index Storyboard content because it is rendered client side via API calls.
These first two problems are related. There are apparently fixes for known performance issues and other long-standing bugs that have yet to be deployed as we need to update the deployment platform to a newer version of python.
Options
- Update the Storyboard deployment and see if that improves things enough to make people happy.
- Migrate projects onto one or more different issue trackers.
The first option would almost certainly need someone to step up and help out. But before we do that it is probably worthwhile to solicit feedback indicating people would want to continue to use storyboard if its performance and other usability issues are addressed.
The second option opens us to a tremendous number of different possibilities. Launchpad, Gitea, GitHub, Bugzilla, Trac, Redmine, etc. I think for this discussion to be productive we should avoid digging too deeply into these options now. And instead determine if Storyboard is something that we as a community want to try and keep alive. Once we've answered that question we can shift gears to this option if necessary.
We would love to hear your feedback. Additional user issues with storyboard, interest in updating/maintaining Storyboard (or the opposite), and thoughts on whether or not addressing known problems with the service would be sufficient to make people want to keep using it are all helpful.
As Sean mentioned, as a team (nova) we are going to discontinue use of storyboard for the placement project and start using launchpad again to make things consistent between nova and placement.
Launchpad also works well for tracking bug fix backports because you can "target to series" a single bug to add older releases to it. Backport patches get automatically posted on launchpad by the infra tooling without the need to create a new Task for each backport and adjusting the commit message of the backport to reference that Task.
That aside, I can share a little feedback about storyboard based on my experience using it for placement and openstackclient.
It might boil down to the first problem you listed "storyboard is slow" but I have found the search function to be unusable. A frequent workflow for me is to search for existing bugs in a project based on a keyword in the title, summary, or comments. With storyboard I haven't been able to succeed in doing that. From what I understand, you are supposed to be able to scope the search by project:<name> but the search will not accept it unless you choose it from the dropdown box that is supposed to appear. The dropdown populates extremely slowly or sometimes not at all. I realize I can just go to a project and choose to show 1000 items per page and use the browser search on the titles instead, but that won't help for keywords in the summary or comments.
Storyboard also isn't _as_ easy for the aforementioned patch backporting that happens constantly in nova. We could add a Task per older release to a Story and adjust the backport patch commit messages to reference the matching Tasks (this is essentially what I have to do downstream and it can be tedious 😇). Not a huge deal but in comparison not as easy as launchpad.
Other than that, I don't have any issues with storyboard. It's just because I use search functions so often in bug trackers in general, it happens to be not so usable for me overall.
as a concreate example and to refersh my memory of using story board i tried to navagate to the placment project yesterday. to do that i searched for it in the projects tab as openstack/placement https://storyboard.openstack.org/#!/project/list?q=openstack%2Fplacement
as you can porbaly see its not in the list of results
if i just seach for placement https://storyboard.openstack.org/#!/project/list?q=placement its the last result with the title openstack/placement ...
if we click on that https://storyboard.openstack.org/#!/project/openstack/placement and say take the 3rd bug "Bug in placement conf file for Apache HTTPD" and seach for placement and HTTPD
https://storyboard.openstack.org/#!/search?q=placement%20HTTPD&title=pla...
its not in the lsit of results
if i use the full title https://storyboard.openstack.org/#!/search?q=Bug%20in%20placement%20conf%20f... also not there
however the popup that you get if you wait actully finds the story.
this UX makes story board feel like perl. you write it once and never read it again because you cant trivially find things using either the seach fucntionality or paging though the bugs. ile go to https://storyboard.openstack.org/#!/project/openstack/placement and set the limit to 100 or 1000 and using your broser to search.
i know it has some nice feature liek being ablt to create boards and worklist ectra to tag and track things bug the out of box or new user expeince is pretty bad if you dont actully go build better views in it as a tool.
for example and not picking on anyoen in particalar this board created by the monasca team https://storyboard.openstack.org/#!/board/190 looks pretty nice. its kanban inspired, clear to see and a arguablly niceer way visualise things the an etherpad for cordinating reviews but that isnt a day to day pain point for us in the same way fileing tasks for backports and updatign the commit message woudl be or searching for exising bugs.
there defintly are some nice design element to what storyboard was trying to enable but in its current hosted incarnation it makes our life harder not simpler.
if we as a comunity were to move to somethign other then storyboard and there was an objection to using launchpad then the 3 i would evauluate are github issues, gitea issues if we want to self host it or gihttps://storyboard.openstack.org/#!/story/2009315t-bug (https://github.com/MichaelMure/git-bug) the main blocker for gitia beside our current installtion not being designed to do it is the lack of Confidential bugs for security issues https://github.com/go-gitea/gitea/issues/3217 i assume sotryborad can do that but gitia and likely git-bug cant. we dont have to deal with a lot of secuity bug but its imporant that when we do we can use the same tool as regular bugs to track it so that its simple for people to correctly file secuiryt bugs.
the other issue si have with story boad that if address would make me more accpting with usign it is how you view/manage stories at the project level in your dashboard https://storyboard.openstack.org/#!/dashboard/stories you have this nice filter stories dropdown with check boxes however you cant filter on the subtask states of todo progres review invalid and merged. or on lables/tags. since everythign starts with a story that means both bugs and features are stories and since you cant filter on lables you cant filter in that view.
https://storyboard.openstack.org/#!/project/openstack/placement that is also true of the project view althought there its worse since the stories are displayed in tab base on active, meged and invalid state. those tabsl reload when you click on them so you also cant swithc beteen them simply. without the abilty to filter stories on tag/labes i cant get a bug or feature view without createing a borad myself. its extra fustrating since the tags are displayed on the page so i can clearlly see what ones are bugs or rfes but cant filter. i also cant find all stories that are "untriaged" since i cant display only the stories without tags.
i can almost get there with https://storyboard.openstack.org/#!/story/list?status=active&project_id=... that allows be to quickly filter to a proeject and look for a spcific tag, in this case placement and bug but i cant do "!= bug | != rfe" or find all stories without the "triaged" tag ectra so wee what are the new issues that as a bug triager i
while writing this reply i spend a littel tiem trying to create a boad to adress these issues and you can mostly hide some of them https://storyboard.openstack.org/#!/board/254 its simple to get all the untiraged issues, rfes adn bugs and group them. where you start hitting rough edges is when you want to dig deeper. storyboard allow syou to filter on storay status (merged invalid active) but that does not actully work properly. going back to the httpd bugs https://storyboard.openstack.org/#!/story/2009315 it has one task in todo and has the bug tag its in the all bug list bug does not show up in the bug backlog. the fixed bugs has 5 listed which is nice. what is not nice is if i look for stories in status merged for placment with the bug key its empty. i has to also seach for bugs with the fixed tag which has to be manulaly added.
so while at first glance it looks liek its easy to adress the isseus i raised jsut creating boards to provide the view you need when you try you hit roadblocks pretty quickly. the view also does not show tags or allow you to filter within the view
storyboad had a lot of potential and some nice features planned but the current install feels like a beta and not something that is ready for production use. it was mentioned this is an old verions. if the isntnace coudl be updated and some/all of these issues have been adress already then im not against trying it for another release but if noti really think its time to move on. its not form a lack of trying to use story borad that i dislike it. its form using it to try and find things.
i know this may come across overly negitive but i wanted to give feedback on the frustratiosn we have had so that if there are people that can work on adressing it we could continue to use it. in my day job i currently have to use downstream:(jira, bugzilla, trello) and upstream:(github issues, storyboard, launchpad) of those tools whiel storyboad is arguable better the bugzilla in every way excpte searching/grouping issues that alone makes it the hardest tool for me to use out of all of them. none of them are perferct and i can see why the story board team built it but it does not align well to projects that need to maintain and backport our code across multiple releases.
The goal here isn't to try and convince anyone they should use Storyboard. Instead we're trying to understand if there are those that would like to keep using Storyboard, and if so, what effort would be necessary to make that possible. Once we've sorted this out we can have a followup discussion on what would be necessary to support projects that don't want to use Storyboard any longer.
Clark
On Wed, Oct 26, 2022, at 4:22 AM, Artem Goncharov wrote:
My few cents
snip (not to exclude the feedback, but I'm going to try and revive this discussion and move it forward in a way that is actionable).
It has been a while since we received any feedback on this thread. All of the feedback we have received so far has been from those looking to migrate to something other than Storyboard.
If there is anyone out there that would like to continue using storyboard now would be a great time to provide that feedback. This is valuable even if you don't have time to dedicate towards reviving the project or its deployment. Please let us know if you have this opinion.
From all user-facing projects I am taking care of I place my “-1” to Storyboard. It should not only fit our dev processes, but be easy and intuitive to all users trying to report bugs.
Storyboard exists because the OpenStack project at one time felt that the alternative tools did not properly fit OpenStack's dev process needs. Based on the feedback we've seen so far, I think that OpenStack's needs have changed, but also Storyboard may not have adequately addressed some of those special needs either. We have also seen feedback from OpenStack projects indicating that the lack of consistency between bug tracking tools has been problematic for collaboration.
It would probably be prudent for the OpenStack project to reevaluate what its needs are for issue tracking to ensure whatever decisions are made are cohesive enough to avoid painful disjointed tool use while also sufficiently meeting the needs of OpenStack developers. The OpenDev service-discuss list is a poor forum for this discussion, but the openstack-discuss mailing list would probably be a good place to have that discussion then any conclusions from there can be brought back to this thread.
On the OpenDev side of things, we should try to get StarylingX and Zuul to chime in. Then once we've got cross project info we can work towards making decisions for OpenDev that best address the needs of our various users.
Artem
Hello,
From Kolla OpenStack projects perspective - we’ve been using Storyboard for Kayobe and Launchpad for the rest. The topic has emerged multiple times to have one tool for all projects inside Kolla family (Kolla, Kolla-Ansible, Kayobe) - but we’ve never came to an agreement to move to Storyboard (because of issues mentioned previously).
Has anybody investigated tooling for moving from Storyboard to Launchpad?
Michal
On 7 Nov 2022, at 18:28, Clark Boylan cboylan@sapwetik.org wrote:
On Wed, Oct 26, 2022, at 4:22 AM, Artem Goncharov wrote:
My few cents
snip (not to exclude the feedback, but I'm going to try and revive this discussion and move it forward in a way that is actionable).
It has been a while since we received any feedback on this thread. All of the feedback we have received so far has been from those looking to migrate to something other than Storyboard.
If there is anyone out there that would like to continue using storyboard now would be a great time to provide that feedback. This is valuable even if you don't have time to dedicate towards reviving the project or its deployment. Please let us know if you have this opinion.
From all user-facing projects I am taking care of I place my “-1” to Storyboard. It should not only fit our dev processes, but be easy and intuitive to all users trying to report bugs.
Storyboard exists because the OpenStack project at one time felt that the alternative tools did not properly fit OpenStack's dev process needs. Based on the feedback we've seen so far, I think that OpenStack's needs have changed, but also Storyboard may not have adequately addressed some of those special needs either. We have also seen feedback from OpenStack projects indicating that the lack of consistency between bug tracking tools has been problematic for collaboration.
It would probably be prudent for the OpenStack project to reevaluate what its needs are for issue tracking to ensure whatever decisions are made are cohesive enough to avoid painful disjointed tool use while also sufficiently meeting the needs of OpenStack developers. The OpenDev service-discuss list is a poor forum for this discussion, but the openstack-discuss mailing list would probably be a good place to have that discussion then any conclusions from there can be brought back to this thread.
On the OpenDev side of things, we should try to get StarylingX and Zuul to chime in. Then once we've got cross project info we can work towards making decisions for OpenDev that best address the needs of our various users.
Artem
On Tue, Oct 25, 2022, at 10:19 AM, Clark Boylan wrote:
Hello,
There have apparently been disparate discussions among different projects on whether or not they want to continue using Storyboard and what alternatives they should consider. Having these discussion is healthy, but I think we should try to have them in the open with a broad audience to ensure we've considered all the various moving parts involved. I'll do my best to kick start that discussion here in this thread.
snip
The goal here isn't to try and convince anyone they should use Storyboard. Instead we're trying to understand if there are those that would like to keep using Storyboard, and if so, what effort would be necessary to make that possible. Once we've sorted this out we can have a followup discussion on what would be necessary to support projects that don't want to use Storyboard any longer.
Its been a month since I kicked this discussion off. Since then we've had good feedback on struggles with using Storyboard. We've also heard from some projects that consistency of tooling is useful to them which is part of their motivation for migrating away from Storyboard.
What we haven't heard from is anyone motivated to help maintain the deployment of Storyboard or the Storyboard software itself. I think this puts OpenDev in an awkward position. Storyboard was built to try and address OpenStack's specific needs around issue tracking. Unfortunately, it also seems clear that Storyboard isn't currently meeting those needs for various reasons, and OpenStack isn't stepping up to try and address that. Currently that means OpenDev is an adoptive parent for the project and is clearly not doing a good enough job to keep the service happy.
Where does that leave OpenDev? I think we have a few potential options for improving the status quo:
* Properly adopt storyboard. Make updating the deployment of storyboard a priority and take on maintenance of the software itself to try and address the issues that have been called out that are not already fixed. This option is unlikely to be successful without help, and we haven't seen any new interest in helping. We would also likely need to help those looking to move regardless of this changes of focus. Which creates an overlap with the next option. * Migrate Storyboard users to another tool and shutdown Storyboard. This option is not without costs either. We'll have to determine how much data preservation is necessary either by creating some sort of read only archive or migrating data from Storyboard into whatever new system is chosen. We would also need to determine what to migrate to and do any necessary work to ensure that service is running. * Many of our users continue to use launchpad and a number of the discussions at the PTG were around moving from stroyboard to LP. This may be an easy option, and possibly the desired option for many given the discussion at the PTG. * Some have suggested using Gitea. While this is theoretically possible there needs to be investigation, testing, and planning to update our Gitea deployment properly to support this. In particular our Gitea deployment is actually 8 independent read only Giteas. Because issues would require authentication and writing content to Gitea we would need to sort that out with a Gitea cluster via updating deployment. Also, we can fairly easily get away with disabling Gitea functionality that we do not want enabled (pull requests, packages, etc) when it is installed as a read only system, but that is potentially more difficult once users can write to the system. Theoretically possible but will require someone to do a fair bit of engineering work. * Insert your ideas here.
None of these options are going to make everyone happy, and all of them present non zero effort on our part. I don't have a strong opinion yet on what our best option is and would love to hear thoughts from those who may have other ideas or interest in a specific option.
Clark
On Mon, 28 Nov 2022, Clark Boylan wrote:
- Properly adopt storyboard. Make updating the deployment of storyboard
a priority and take on maintenance of the software itself to try and address the issues that have been called out that are not already fixed. This option is unlikely to be successful without help, and we haven't seen any new interest in helping. We would also likely need to help those looking to move regardless of this changes of focus. Which creates an overlap with the next option.
I am mostly lurking here but I decided to have a quick look at the Storyboard backend and I think the performance is so bad that it has a priority of "Unbreak Now" if some projects are even thinking about staying there.
Some API queries to the backend took 2 to 6 seconds to complete when invoked from Europe.
Anything like usability/frontend/missing features is secondary to that. I think it is worth fixing the perfomance even if the projects decide to switch away - the migration can take time.
Why is it so bad? Who can have a look at the machine running it and the database? Would that be possible to obtain a possibly redacted copy of a MySQL database to reproduce the issues locally?
I could have a quick look at it but I am not sure if some crisis group could be built to address this promptly and without red tape?
I can see some unfortunate architectural decisions in the code but even with them it should not perform that badly for the amount of data we have. But it is all guessing until some real performance data can be collected from the live environment.
I have joined #storyboard as "saper" to discuss details.
Marcin (I made some tiny contributions to git-review and gerrit in the past, that's why I'm here)
On Wed, Nov 30, 2022, at 7:20 AM, Marcin Cieslak wrote:
On Mon, 28 Nov 2022, Clark Boylan wrote:
- Properly adopt storyboard. Make updating the deployment of storyboard
a priority and take on maintenance of the software itself to try and address the issues that have been called out that are not already fixed. This option is unlikely to be successful without help, and we haven't seen any new interest in helping. We would also likely need to help those looking to move regardless of this changes of focus. Which creates an overlap with the next option.
I am mostly lurking here but I decided to have a quick look at the Storyboard backend and I think the performance is so bad that it has a priority of "Unbreak Now" if some projects are even thinking about staying there.
Some API queries to the backend took 2 to 6 seconds to complete when invoked from Europe.
Anything like usability/frontend/missing features is secondary to that. I think it is worth fixing the perfomance even if the projects decide to switch away - the migration can take time.
Why is it so bad? Who can have a look at the machine running it and the database? Would that be possible to obtain a possibly redacted copy of a MySQL database to reproduce the issues locally?
I could have a quick look at it but I am not sure if some crisis group could be built to address this promptly and without red tape?
Half of my emails to this thread have asked if anyone is interested in stepping up to do the necessary work without any response. A group could be organized to help, but no one seems interested.
I can see some unfortunate architectural decisions in the code but even with them it should not perform that badly for the amount of data we have. But it is all guessing until some real performance data can be collected from the live environment.
It is my understanding that a number of these issues have been addressed, but at some point the storyboard code base updated in such a way that our aging configuration management for it cannot deploy the latest version. For this reason the first step that should be taken is to update the server and its configuration management so that accurate information can be collected against the current codebase. We can fix the codebase all we want, but if we aren't deploying it we won't see those improvements.
All that to say I don't think a db dump is helpful at this point. What we need are people interested in rewriting the configuration management and upgrading the server if improving storyboard is a goal. Then we can profile, patch, and deploy fixes to improve things from there.
I have joined #storyboard as "saper" to discuss details.
Marcin (I made some tiny contributions to git-review and gerrit in the past, that's why I'm here) Attachments:
- smime.p7s
participants (6)
-
Artem Goncharov
-
Clark Boylan
-
Marcin Cieslak
-
melanie witt
-
Michał Nasiadka
-
Sean Mooney