Storyboard Needs and Alternatives

[Clark Boylan]

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