Hi Jeremy,
First of all, thank you for the writeup, it is really helpful and contributes a lot to the discussion.
On Thu, Sep 10, 2020 at 5:59 PM Jeremy Stanley fungi@yuggoth.org wrote:
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.
I feel you. I could not so far convince anyone to support me to work on it, mostly because Jira/GitHub/GitLab/Launchpad exists. Not to mention many small internal projects are happy with just Trello. :-) I feel this might be due to the audience Storyboard tries to cater to (larger cross-project work) which is not a common requirement (or rather just hard to organise for oneself).
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.
That would be awesome.
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."
Ouch, you are right. I should have picked my words more responsibly. I guess this was caused by one of longer sessions on Storyboard. I sincerely apologise and hope nobody was offended. As I wrote further below that line, I really appreciate Storyboard otherwise. It's just that it does not really shine compared to <insert practically any other competing issue tracking software here> these days.
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.
I know this issue a bit. Hard to make everyone like each other. As for Storyboard, since it still uses Ubuntu One for now, I could not obviously see that as counting in favour of Storyboard. :-)
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.
You are right there that we can't necessarily solve this for everyone. But at the moment it's confusing in that projects are partially there and partially elsewhere *because of the recommendation*. Obviously one can't do anything about escalation to libvirt/qemu/kernel bugzillas but those are external projects. For OpenStack projects we can have better guidelines.
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.
I could not express it better.
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.
I see how that could sound harsh as well. I meant its confusing effect rather than the need to disable Storyboard altogether and make it disappear, no.
All in all, I'd love to see Storyboard flourish as the approach appeals to me, just the UX is far from ideal at the moment. I meant this thread to be against the recommendation, not the software/instance itself. The recommendation introduced a feeling that Storyboard *should* be used, Launchpad is not really mentioned any longer either. To reiterate, I don't think it sounds like it *must* be used (and surely is not a requirement) but *should* is enough to cause bad experience for both sides (users trying to report and teams trying to keep track of reported issues).
-- Jeremy Stanley