On 2020-09-10 13:10:44 +0200 (+0200), Radosław Piliszek wrote:
The subject is the question I am posing. The general recommendation is to use Storyboard for new projects [1].
I agree that recommending a service without context is likely to cause problems. StoryBoard is a service provided within OpenDev, and I don't think we anticipate stopping to provide that service to projects who wish to make use of it. Its use is not at all mandatory. The deployment of it in OpenDev is at least minimally functional and sufficient for light duty, though I understand people who are in a situation of needing to interact with their defect and task trackers constantly likely find some aspects of it frustrating.
However, Storyboard does not seem to be receiving enough love recently [2] [3].
Yep, nobody works on it full-time and it could use some additional developers, reviewers and sysadmins to help regain momentum. For example, I could use some help figuring out fine-grained user permissions for Rackspace's Swift-like object store, which is currently blocking more effective vetting of the proposed client-side support for Adam's story attachments work. We would also love assistance getting the current Puppet module we're managing our deployment with replaced by Ansible/docker-compose orchestration of the container images we've started publishing to DockerHub. Even just helping us triage and tag new stories for opendev/storyboard and opendev/storyboard-webclient would be appreciated.
It's generally deemed as slow [4]
Preliminary testing suggests https://review.opendev.org/742046 will increase performance for the queries behind most common views by an order of magnitude or more.
and is missing quite a few usability enhancements [2]. Considering the alternative, and the actual previous recommendation, is Launchpad, I find it no-brainer to revert to recommending Launchpad still, even paving a way for projects wishing to escape the Storyboard nightmare. :-)
The smiley doesn't particularly soften the fact that you just rudely referred to the product of someone's hard work and volunteered time as a "nightmare." One problem we were hoping to solve which Launchpad doesn't help us with is that we have a number of potential contributors and users who have balked at collaborating through OpenDev because our services require them to have an "Ubuntu" login even though they're not users of (and perhaps work for rivals/competitors of) that distro. Once our Central Auth/SSO spec reaches implementation, being able to offer some sort of cross-project task and defect tracking integrated with our Gerrit code reviews, and using the same authentication, gives projects who want to not require members of their communities to have an UbuntuOne account that option.
Don't get me wrong, I really like the Story/Task orientation but Storyboard results in a frustrating experience. In addition to being slow, it has issues with search/filter, sorting and pagination which make issue browsing an utter pain. I know Launchpad is not without issues but it's certainly a much better platform at the moment. And many projects are still there.
Again, I think Launchpad is a fine platform for some projects. It's designed around bug tracking for packaging work targeting various Ubuntu releases, but that doesn't mean it can't also be used effectively for other sorts of activities (as evidenced by the many software projects who do). They've recently improved their development environment setup and build instructions too, so working on a patch to fix something there isn't nearly as challenging as it once was. If you use Launchpad and want to improve some aspect of it, I wholeheartedly encourage you to try to collaborate with its maintainers on that. And if projects want to move to (or back to) Launchpad, I don't have a problem with that and am happy to get them database exports of their SB stories and tasks... I think we can just set the corresponding project entries to inactive so they can't be selected for new tasks, though that will need a bit of testing to confirm.
The Launchpad-Storyboard split is also introducing confusion for users [5] and coordinability issues for teams as we need to cross-link manually to get proper visibility.
I'm not entirely convinced. Users are going to be confused and sometimes open bugs in the wrong places regardless. Back when the OpenStack Infra team existed and had a catch-all LP project for tracking infrastructure-related issues and incidents, users often got equally confused and opened Nova bugs under that. They also still constantly wander into the #openstack-infra IRC channel asking us how to run OpenStack. Turning off StoryBoard won't solve that. Honestly, I doubt anything will (or even can) solve that. As for cross-linking, you have to do that today if someone mistakenly opens a Nova bug which turns out to be a Qemu or KVM issue instead. It's unrealistic to expect all F/LOSS projects to use one common tracker.
All in all, I ask you to consider recommending Launchpad again and encourage OpenStack projects to move to Launchpad.
I agree we shouldn't be recommending StoryBoard over other platforms without providing some context as to when projects might consider using it. I also won't attempt to dissuade anyone who wants to move their tracking to other open source based services like (but not necessarily limited to) Launchpad. Different projects have different needs and no one work management tool is going to satisfy everyone.
Extra note: I find it in a similar spot as ask.o.o - nice it has been tried, but unfortunately it did not stand the test of time.
[1] https://docs.opendev.org/opendev/infra-manual/latest/creators.html [2] https://storyboard.openstack.org/#!/project/opendev/storyboard [3] https://opendev.org/opendev/storyboard/commits/branch/master [4] https://storyboard.openstack.org/#!/story/2007829 [5] https://storyboard.openstack.org/#!/story/2000890
I don't personally think it's quite the same situation as Ask OpenStack, though I can see where you might draw parallels. -- Jeremy Stanley