[openstack-dev] [StoryBoard] PTG Summary
kennelson11 at gmail.com
Thu Sep 20 21:15:25 UTC 2018
Hello Lovers of Task Tracking!
So! We talked about a lot of things, and I went to a lot of rooms to talk
about StoryBoard related things and it was already a week ago so bear with
We had a lot of good discussions as we were able to include SotK in
discussions via videocalling. We also had the privilege of our outreachy
intern to come all the way from Cairo to Denver to join us :)
Onto the summaries!
This topic has started coming up with increasing regularity. Currently,
StoryBoard doesn’t support attachments, but it’s a feature that several
projects claim to be blocking their migration. The current work around is
either to trim down logs and paste the relevant section, or to host the
file elsewhere and link to its location. After consulting with the
infrastructure team, we concluded that currently, there is no donated
storage. The next step is for me to draft a spec detailing our requirements
and implementation details and then to include infra on the review to help
them have something concrete to go to vendors with. For notes on the
proposed method see the etherpad.
One other thing discussed during this topic was how we could maybe migrate
the current attachments. This isn’t supported by the migration script at
this point, but it’s something we could write a separate script for. It
should be separate because it would be a painfully slow process and we
wouldn’t want to slow down the migration script more than it already is by
the Launchpad API. The attachments script would be run after the initial
migration; that being said, everything still persists in Launchpad so
things can still be referenced there.
Handling Duplicate Stories
This is also an ongoing topic for discussion. Duplicate stories if not
handled properly could dilute the database as we get more projects migrated
over. The plan we settled on is to add a ‘Mark as Duplicate’ button to the
webclient and corresponding functions to the API. The user would be
prompted for a link to the master story. The master story would get a new
timeline event that would have the link to the duplicate and the duplicate
story would have all tasks auto marked as invalid (aside from those marked
as merged) so that the story then shows as inactive. The duplicate story
could also get a timeline event that explains what happened and links to
the master story. I’ve yet to create a story for all of this, but it’s on
my todo list.
Handling Thousands of Comments Per Story
There’s this special flower story that has literally thousands of
comments on it because of all of the gerrit comments being added to the
timeline for all the patches for all the tasks. Rendering of the timeline
portion of the webpage in the webclient is virtually impossible. It will
load the tasks and then hang forever. The discussion around this boiled
down to this: other task trackers also can’t handle this and there is a
better way to divvy up the story into several stories and contain them in a
worklist for future, similar work. For now, users can select what they want
to load in their timeline views for stories, so by unmarking all of the
timeline events in their preferences, the story will load completely sans
timeline details. Another solution we discussed to help alleviate the
timeline load on stories with lots of tasks is to have a task field that
links to the review, rather than a comment from gerrit every time a new
patch gets pushed. Essentially we want to focus on cleaning up the timeline
rather than just going straight to a pagination type of solution. It was
also concluded that we want to add another user preference for page sizes
of 1000. Tasks have not been created in the story related to this issue
yet, but its on my todo list.
Project Group Descriptions
There was a request to have project group descriptions, but currently there
is nothing in the API handling this. Discussion concluded with agreement
that this shouldn’t be too difficult. All that needs to happen is a few
additions to the API and the connection to managing group definitions in
project-config. I still need to make a story for this.
There was an infrastructure mailing list thread a little while back that
kicked off discussion on this topic. It was received as an interesting idea
and could help with the adoption of StoryBoard outside of OpenStack. The
biggest concern was communicating to users that are seeing the webclient
rendered in some other language that they still need to create
tasks/stories/worklists/boards in English or whatever the default language
is for the organization that is hosting StoryBoard. This could be a banner
when someone logs in, or something on user’s dashboards. One of the things
for signaling what strings need to be translated. We didn’t really outline
next steps past that as it’s not super high priority, but it’s definitely
an effort we would support if someone wanted to start driving it forward.
Easier Rollback for Webclient Continuous Deployment
With the puppet-storyboard module we deploy from tarballs instead of from
git right now, and we don't preserve earlier tarballs which makes it
difficult to rollback changes when we find issues. There wasn’t a ton of
discussion besides, yes we need to figure this out. Pre-zuulv3 we uploaded
tarballs with the git sha, if we apply that to
Managing Project Coresec Groups
The vast majority of work on private stories has been implemented. Stories
can be marked as private and users can subscribe other users to those
private stories so that only those people can see them. The only
convenience that is currently lacking is adding groups of users (manually
or automatically if in a template story). Groups of users are currently
only managed by StoryBoard admins. We would like to make this managed in a
repository or by proxying gerrit group management. This shouldn’t be too
complicated a change, it would only require some sort of flag being set for
a group definition and then some database migration to sync those groups
into the StoryBoard database. If you have opinions on this topic, it’s not
all set in stone and we would love to hear your thoughts!
It’s become apparent that while the search and type ahead features of
StoryBoard work better than most users think at first glance, it’s an issue
that users struggle with searching as much as they do. We talked about
possible solutions for this aside from writing documentation to cover
searching in the webclient. The solution we talked about most was that it
might be easier for our users if we used the gerrit query language as that
is what the majority of our users are already familiar with. The next step
here is to write a spec for using the gerrit query language- or some other
language if users disagree about using the gerrit language.
Show all OpenStack Repos in StoryBoard?
Are we getting to the point where it would be helpful for the users of
StoryBoard to be able to add tasks to stories for all the repos not already
migrated to StoryBoard? This would be incredibly helpful for things like
release goal tracking where many repos that haven’t been migrated had tasks
that were assigned to governance instead of the actual repo so as to be
able to track everything in a single story. This is something we will want
to take up with the TC during a set of office hours in the next week or so.
Summary & Continuing Conversations
My brain is mush. Hopefully I covered the majority of the important topics
and did them justice! Anyone that was there, please feel free to correct
me. Anyone that wasn’t there that is interested in getting involved with
any of this, please join us in #storyboard on IRC or email us with the
[Storyboard] tag to the dev or infra mailing lists. We also have weekly
meetings on Wednesdays at 19:00 UTC, please join us!
I've got a lot of stories to make/update and tasks to add..
-Kendall Nelson (diablo_rojo)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev