Open Stack

Updates!

On Thu, Sep 20, 2018 at 2:15 PM Kendall Nelson <kennelson11 at gmail.com>
wrote:

> 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
> me.
>
> 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!
>
> Story Attachments
>
> ==============
>
> 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[1].
>
> 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.
>

Turns out there is a story already[5].


>
> Handling Thousands of Comments Per Story
>
> ==================================
>
> There’s this special flower story[2] 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[3], but its on my todo list.
>

Updates story[6].


> 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.
>

Created a story for this[7].


> Translating storyboard-webclient
>
> =========================
>
> 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
> that needs to happen first is to find libraries for javascript and angular
> 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.
>

I made a story[8] for this even though its pretty far down the list of
priorities.


> 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
> publish-openstack-javascript-content, that might help the situation.
>

Made a story for this[9].


> 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!
>

This is the story tracking private stories work[10].


> Searching
>
> ========
>
> 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[4] on Wednesdays at 19:00 UTC, please join us!
>
>
> I've got a lot of stories to make/update and tasks to add..
>
>
> Thanks!
>
> -Kendall Nelson (diablo_rojo)
>
> [1] https://etherpad.openstack.org/p/sb-stein-ptg-planning
>
> [2] https://storyboard.openstack.org/#!/story/2002586
>
> [3] https://storyboard.openstack.org/#!/story/2003525
>
> [4] http://eavesdrop.openstack.org/#StoryBoard_Meeting
>
>
I'm also trying to organize all of the work we are doing in a board. I'm in
the middle of an overhaul atm, but if you want to follow our work, you will
be able to see it here[11]..eventually.

-Kendall (diablo_rojo)

[5] https://storyboard.openstack.org/#!/story/2002136
[6] https://storyboard.openstack.org/#!/story/2003525
[7] https://storyboard.openstack.org/#!/story/2003886
[8] https://storyboard.openstack.org/#!/story/2003887
[9] https://storyboard.openstack.org/#!/story/2003888
[10] https://storyboard.openstack.org/#!/story/2000568
[11] https://storyboard.openstack.org/#!/board/1
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-infra/attachments/20180927/6de44496/attachment-0001.html>