| *** diablo_rojo has quit IRC | 00:19 | |
| *** diablo_rojo has joined #storyboard | 00:34 | |
| *** diablo_rojo has quit IRC | 02:36 | |
| *** diablo_rojo has joined #storyboard | 04:07 | |
| *** diablo_rojo has quit IRC | 06:29 | |
| *** jtomasek has joined #storyboard | 07:50 | |
| *** jtomasek has quit IRC | 07:50 | |
| *** jtomasek has joined #storyboard | 07:51 | |
| *** openstackgerrit has quit IRC | 16:19 | |
| *** krotscheck has quit IRC | 18:20 | |
| *** krotscheck has joined #storyboard | 18:22 | |
| *** Adarfive848 has joined #storyboard | 18:25 | |
| Adarfive848 | ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ A BUSY MEETING IS GOING ON NOW IN #/JOIN ITS A JOINT MEETING WITH THE DISCUSSION OF RE-ENSLAVEMENT OF NIGGERS..MESSAGE CHRONO OR VAP0R FOR DETAILSpduskxk: jpmaxman ssbarnea zaro ▄▄▄▄▄▄▄▄▄▄ | 18:25 |
|---|---|---|
| Adarfive848 | ▄▄▄▄▄▄▄▄▄▄ A BUSY MEETING IS GOING ON NOW IN #/JOIN ITS A JOINT MEETING WITH THE DISCUSSION OF RE-ENSLAVEMENT OF NIGGERS..MESSAGE CHRONO OR VAP0R FOR DETAILSqvmhbx: betherly openstack jmccrory ▄▄▄▄▄▄▄▄▄▄▄ | 18:25 |
| Adarfive848 | ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ A BUSY MEETING IS GOING ON NOW IN #/JOIN ITS A JOINT MEETING WITH THE DISCUSSION OF RE-ENSLAVEMENT OF NIGGERS..MESSAGE CHRONO OR VAP0R FOR DETAILSpwxugvqci: openstack Zara kong ▄▄▄▄▄▄▄▄▄▄ | 18:25 |
| Adarfive848 | ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ A BUSY MEETING IS GOING ON NOW IN #/JOIN ITS A JOINT MEETING WITH THE DISCUSSION OF RE-ENSLAVEMENT OF NIGGERS..MESSAGE CHRONO OR VAP0R FOR DETAILSramar: betherly krotscheck pleia2 ▄▄▄▄▄▄▄ | 18:25 |
| Adarfive848 | ▄▄▄▄▄▄▄▄▄▄▄ A BUSY MEETING IS GOING ON NOW IN #/JOIN ITS A JOINT MEETING WITH THE DISCUSSION OF RE-ENSLAVEMENT OF NIGGERS..MESSAGE CHRONO OR VAP0R FOR DETAILSemvin: pleia2 sparkycollier kong ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ | 18:25 |
| Adarfive848 | â–„â–„â–„â–„â–„â–„â–„â–„â–„â–„â–„â–„â–„â–„â–„â–„â–„â–„â–„ A BUSY MEETING IS GOING ON NOW IN #/JOIN ITS A JOINT MEETING WITH THE DISCUSSION OF RE-ENSLAVEMENT OF NIGGERS..MESSAGE CHRONO OR VAP0R FOR DETAILSywvspvxde: SpamapS jmccrory persia_ â–„â–„â–„â–„â–„â–„â–„â | 18:25 |
| Adarfive848 | ▄▄▄▄▄▄▄▄▄▄ A BUSY MEETING IS GOING ON NOW IN #/JOIN ITS A JOINT MEETING WITH THE DISCUSSION OF RE-ENSLAVEMENT OF NIGGERS..MESSAGE CHRONO OR VAP0R FOR DETAILSljmewxcpzc: jdandrea pleia2 jpmaxman ▄▄▄▄▄▄▄▄▄▄▄▄▄ | 18:25 |
| Adarfive848 | ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ A BUSY MEETING IS GOING ON NOW IN #/JOIN ITS A JOINT MEETING WITH THE DISCUSSION OF RE-ENSLAVEMENT OF NIGGERS..MESSAGE CHRONO OR VAP0R FOR DETAILSftpaztnmbh: v1k0d3n tlbr pleia2 ▄▄▄▄▄▄▄▄▄▄▄ | 18:25 |
| *** v1k0d3n has left #storyboard | 18:26 | |
| *** Adarfive848 has quit IRC | 18:27 | |
| *** diablo_rojo has joined #storyboard | 18:37 | |
| *** krotscheck has quit IRC | 18:39 | |
| *** krotscheck has joined #storyboard | 18:44 | |
| SotK | storyboard meeting in a few minutes in #openstack-meeting! | 18:56 |
| mordred | SotK: tl;dr - the theme process, which involves recompiling the stuff with less but with search paths for some things is *very* hard to get working right in webpack - largely because of relative path issues | 19:28 |
| mordred | SotK: while my original goal with webpack was to use it to completely get rid of Grunt - I think we *might* want to keep it (or switch to gulp) just to do the less compilation, and then have the npm command be "gulp build less && webpack" or something like that | 19:29 |
| mordred | SotK: and have the compiled css from the less build be what webpack treats as source code | 19:30 |
| mordred | SotK: the downside to that is that webpack-dev-server and live content updating wouldn't work for changes to .less files since webpack wouldn't know about them or that they should trigger updates | 19:30 |
| mordred | SotK: other options would be a more substantial rethinking of how the themeing/less/css stuff works including but not limited to considering switching to scss/sass which seems to have a little bit better bootstrap webpack integration support (folks using webpack to compile bootstrap from source seem to be using sass instead of less, so theres more internet help) | 19:33 |
| mordred | SotK: or maybe writing our own webpack plugin that does the thing we need it to do | 19:33 |
| mordred | SotK: anyway - I think the hybrid webpack/gulp approach will allow us to get everything else into webpack except for less, and should set us up to iterate from there | 19:34 |
| Zara | betherly did some work to switch to sass a while back, it should be somewhere in review.openstack.org | 19:34 |
| Zara | will need a rebase by now but that would likely be a good place to start | 19:34 |
| SotK | yeah, its https://review.openstack.org/#/c/379595/ | 19:34 |
| SotK | I think switching to webpack/gulp is the best option to begin with | 19:35 |
| SotK | sounds like its least work anyway | 19:35 |
| mordred | Zara, SotK: cool. I'll queue that up after the webpack/gulp combo works (also, I have learned WAY more about building less than I ever wanted to know) | 19:35 |
| SotK | long-term I would like to switch to using sass instead of less | 19:36 |
| mordred | cool. well, it's good to know that that's a desire | 19:36 |
| mordred | (it's nicer when it's a positive thing rather than "the only way we could get the build chain to work") | 19:36 |
| persia | I think discussion of migration to sass started shortly after the last vancouver summit: it just never became the most pressing issue (and the build chain change is a good reason to finally get around to it) | 19:39 |
| mordred | persia: ++ | 19:40 |
| SotK | persia: indeed | 20:02 |
| * krotscheck enjoyed reading this thread :) | 20:24 | |
| *** jtomasek has quit IRC | 21:34 | |
| *** aspiers has joined #storyboard | 22:31 | |
| aspiers | o/ | 22:31 |
| aspiers | So, the first piece of feedback I have, being totally underqualified to give feedback based on like 10 mins of trying Storyboard, is that apparently tasks can't be marked as blocking on something else? | 22:33 |
| aspiers | Well, actually that's the second; feedback item #0 is that there doesn't seem to be an easily locatable intro guide explaining what Storyboard is, and importantly how it's different from Launchpad, Bugzilla, Trello, Jira etc. etc. | 22:35 |
| aspiers | I thought I already read one last year, but maybe it was a blog post which I lost | 22:35 |
| aspiers | feedback item #2: the search page should have some help on how to search | 22:36 |
| aspiers | feedback item #3: it's a bit confusing to me that creating a new story auto-populates a task with identical description to the story | 22:37 |
| aspiers | stories are different to tasks, so why should they commonly have identical descriptions? | 22:37 |
| diablo_rojo | aspiers, as for a manual, there is a patch out for review if you want to try it out and give some feedback: https://review.openstack.org/#/c/325474/ | 22:38 |
| aspiers | oh cool | 22:38 |
| aspiers | diablo_rojo: hmm, no Zuul job to render that rst as HTML for easier review? | 22:39 |
| diablo_rojo | As for the launchpad/Storyboard mapping, that was a blog post a little while back. | 22:39 |
| diablo_rojo | aspiers, if you click on the 'build-openstack-sphinx-docs' you can see the build | 22:40 |
| aspiers | well that's bizarre, somehow I totally missed that despite looking explicitly for it | 22:41 |
| diablo_rojo | Feedback items 2 & 3 should be easy enough to fix, both webclient tasks I think. Right, SotK ? | 22:41 |
| diablo_rojo | aspiers, no worries :) | 22:41 |
| diablo_rojo | SotK, or Zara can maybe speak to feedback item #1: wrt to dependencies/blocking items | 22:42 |
| aspiers | cool, thanks :) | 22:42 |
| diablo_rojo | aspiers, no problem :) | 22:42 |
| diablo_rojo | If you want to make those two small changes for feedback 2&3 they shouldnt be too bad and I would be happy to review ;) | 22:43 |
| aspiers | I'll have to learn how to deploy it locally first, I guess | 22:44 |
| aspiers | I should deal with this self-healing administravia first, otherwise it'll never get done. I'm too easily distracted by shiny, so please don't tempt me ;-0 | 22:44 |
| diablo_rojo | aspiers, https://docs.openstack.org/infra/storyboard/install/development.html | 22:44 |
| diablo_rojo | shows you how to set it up and mess with it | 22:44 |
| aspiers | yep, I spotted that but haven't read it yet | 22:45 |
| diablo_rojo | aspiers, cool :) Well, make your stories and a todo list. | 22:45 |
| aspiers | the main point of using Storyboard for the self-healing SIG as opposed to say, Trello, was dogfooding Storyboard, so you can probably expect more from me on this :) Also I'm in the UK, like a lot of Storyboard hackers IIRC | 22:46 |
| krotscheck | aspiers: You'd be correct, both SotK, persia, and Zara are out of... manchester, I think? | 22:48 |
| Zara | yep | 22:48 |
| persia | Lack of dependencies was intentional, because of the many (conflicting) semantic mappings people put on bug dependencies. Using the behaviour from Launchpad was easier (plus I don't remember the wording of mpt's exceedingly compelling arguments about why) | 22:49 |
| Zara | as far as auto task desc goes, it's just that some task is necessary to link story to project | 22:49 |
| Zara | and that seemed like a sensible default desc | 22:49 |
| persia | My memory is that new-story-autopopulates-task-with-same-name was a feature request, by folk who were a bit confused about how to assign a story to a project initially. I think that use of the in-review story submission form should make that a bit more sensible. | 22:50 |
| Zara | (am typing from phone) | 22:50 |
| persia | Despite the input method, your memory of story-and-task-with-same-description is probably better than mine :) | 22:50 |
| persia | I think #2 is better written "the search interface, and distinctions between "search" and "browse" are very confusing and potentially broken in a variety of ways. | 22:51 |
| krotscheck | I recall building that, actually. There was a constraint that a story had to have at least one task, and rather than force someone to enter _two_ description fields we defaulted the first task to the story description, expecting it to be updated by the person entering the task. That... didn't turn out to be the case though. | 22:51 |
| Zara | there's a story somewhere 'various search fixes' | 22:51 |
| persia | Help would be better, but I think there are still a number of confusing bits, despite the big search->browse migration that was supposed to make it a bit more intuitive. | 22:51 |
| krotscheck | Lordy, that was a long time ago. | 22:53 |
| krotscheck | I'm just gonna go lurk again. | 22:53 |
| * krotscheck poofs | 22:53 | |
| Zara | haha | 22:53 |
| persia | https://storyboard.openstack.org/#!/story/list?status=active&project_group_id=57&q=search actually has a number of search-related stories | 22:54 |
| krotscheck | argh my name's still on some of those! | 22:54 |
| * krotscheck hides | 22:54 | |
| Zara | the one that has a comment with plan for future is 'various search fixes' iirc | 22:54 |
| Zara | lol | 22:54 |
| persia | https://storyboard.openstack.org/#!/story/2000402 ? | 22:55 |
| Zara | yup | 22:56 |
| persia | I think a fair amount of that one got implemented (although not all of it) | 22:56 |
| persia | But actually making search work sensibly probably needs someone to review how the interface actually behaves, and the set of search stories, and spec out something sensible for implenentation in both code and docs. | 22:56 |
| persia | I suspect that would be easier than trying to document the various behaviours and corner cases. | 22:57 |
| persia | (or write beginner-focused end-user help for the current state) | 22:57 |
| aspiers | krotscheck: why is there a constraint that a story has at least one task? IMHO the best solution would be to ditch that, and 2nd best would be to force someone to enter two description fields, which is inconvenient but at least then you don't encourage creation of tasks with incorrect descriptions | 23:00 |
| krotscheck | aspiers: This was 3 years ago. I really don't recall the details. | 23:01 |
| aspiers | haha ;-) | 23:01 |
| Zara | stories are cross-project, the task is there to link yhe story to a project | 23:01 |
| * krotscheck hasn't been working on OpenStack since HPE laid-off/sold their entire upstream team in September 2016. | 23:01 | |
| aspiers | Zara: why does it need to be linked to any project though, I wonder ... | 23:02 |
| aspiers | krotscheck: come and join SUSE ;-) | 23:02 |
| Zara | it's so that the team working on affected projects can find it :) | 23:03 |
| Zara | so eg story goes 'update python in some projects' | 23:03 |
| aspiers | Zara: presumably it's possible to search for a story by title? | 23:03 |
| aspiers | if it's not yet marked as affecting any projects, that seems perfectly reasonable to me | 23:04 |
| Zara | then a task per project like 'update python in foo' so can see where it has been and where it still needs to be | 23:04 |
| Zara | not a great example but that's the reasoning | 23:04 |
| persia | aspiers: It is possible, but I believe the argument was that these stories would be lost, much like the bugs-with-no-project in launchpad, which I believe nobody ever examines except for fun. | 23:04 |
| aspiers | I totally see the value in the link between stories and projects, but I still don't get why that link is *required* as part of initial creation | 23:05 |
| Zara | ('migrate project to storyboard' is a rl example) | 23:05 |
| Zara | also yeah to stop them getting lost | 23:05 |
| aspiers | persia: presumably they could be easily found via a "reverse orphans" worklist | 23:05 |
| persia | Heh. Someone disabled the view for LP bugs without any tasks assigned to projects. | 23:06 |
| aspiers | and wouldn't they still appear on the dashboard of the story creator? | 23:06 |
| aspiers | if there was a real danger of them getting lost, to me that would sound like a separate UI/UX bug, rather than a reason to not allow them | 23:07 |
| persia | aspiers: Yes, they would appear on the dashboard, although I think that individual dashboard wasn't something considered in the initial data model design (which was hugely based on LP, except "fixing" some annoyances that existed in LP, like not allowing two tasks for one project in one bug) | 23:07 |
| aspiers | ah OK | 23:07 |
| Zara | yeah it is slowly evolving :) | 23:07 |
| persia | The rule "a story must have a task" might not apply today, and might apply even less once projects start to adopt the "new story" interface, which allows projects to pre-populate some things. | 23:08 |
| persia | But unpacking it would need some digging, as I think there are a lot of assumptions that stories all have at least one task. | 23:08 |
| aspiers | got it | 23:08 |
| persia | e.g. "What is the status of a story"? | 23:09 |
| aspiers | is it worth creating a story for that? | 23:09 |
| persia | aspiers: If you want a discussion thread about it in a less transient forum, such a story is probably the right place for the discussion. | 23:09 |
| Zara | +1 | 23:09 |
| persia | If you want someone to do it, I'm not sure Storyboard gets enough love that anyone grabs random stories from the queue for implementation. | 23:10 |
| aspiers | and also the more generalized version of that question: if I think I spot something which smells like a bug (UI/UX or otherwise), is it OK just to file a story? i.e. is there some non-annoying way to mark it resolved as a duplicate or wontfix if my submission was wrong due to ignorance? | 23:10 |
| Zara | sure, go for it :) | 23:10 |
| Zara | we can set tasks to invalid | 23:11 |
| persia | I don't think duplicate was ever implemented, but "Invaild" and "Merged" both work | 23:11 |
| aspiers | persia: well yeah, that's the other side of that question: do we want stories/tasks lying around even if noone's likely to work on them soon? | 23:11 |
| aspiers | also, can *stories* be marked as invalid? | 23:12 |
| * persia vaguely remembers duplicate implementation being blocked on resolving a mechanism for projects to opt-in or opt-out, depending on whether they were likely to have lots of superficially similar appearing bugs with different underlying issues. | 23:12 | |
| persia | A story has no inherent status: story status is due to the status of tasks on that story: one of the many things that would need to be reviewed to have taskless stories. | 23:12 |
| persia | Same as LP, which was expected to be familiar to OpenStack folk, but for various reasons StoryBoard adoption kept getting postponed another cycle, so now it is a less safe assumption that everyone knows LP. | 23:13 |
| persia | Personally, I'm of the school that a well-maintained set of feature requests is attractive to new developers: there is an easy answer to "what can I do" or "where can I start". I don't believe the storyboard stories list is yet sufficiently out of control that it doesn't serve that purpose. | 23:14 |
| aspiers | That makes sense to me | 23:14 |
| persia | When there are thousands of untriaged items opened for each closed, it becomes more useful to admit that X% are just going to be ignored completely. | 23:15 |
| persia | One of the points of Storyboard vs. LP was to try to encourage more coordination of related things, such that a project could manage a set of stories as a roadmap, rather than just having a massive list of bugs. | 23:15 |
| krotscheck | aspiers: Tried. "We don't have use for someone like you" from the CTO himself. | 23:16 |
| persia | In practice, it ends up being an interesting tradeoff between having a small number of tasks per story and a large number: I'm not sure there is a good compromise, as I've seen different teams move in different directions with great success (some teams complaining about having more than one task per story, and some having stories (or LP bugs) with hundreds of tasks) | 23:16 |
| aspiers | krotscheck: wtf, really? | 23:17 |
| aspiers | with respect, our CTO is not the right person to be judging that | 23:17 |
| krotscheck | aspiers: At the time, I was billing myself as a JS/UI expert, with no interest in working on horizon. | 23:18 |
| * krotscheck shrugs | 23:18 | |
| aspiers | well we *certainly* have JS/UI work outside horizon | 23:18 |
| krotscheck | I have a fantastic position here at VMware, so I'm happy. Not that I wouldn't mind moving back to germany (Ich bin ja Staatsbürger), but for the time being I'm happy :) | 23:19 |
| aspiers | haha | 23:19 |
| krotscheck | I have to say that OpenStack was a _big_ reason I was hired though. The whole "Test the crap out of everything before merging" approach here has served me very well. | 23:19 |
| aspiers | TBH I'm surprised you even ended up talking to the CTO about that. Normally those discussions are with hiring managers who actually know the details of the work we need people on | 23:19 |
| krotscheck | aspiers: He was at the Austin summit. | 23:20 |
| aspiers | krotscheck: +1000 on that | 23:20 |
| aspiers | krotscheck: sure, just saying he's not necessarily the right person for those lower-level discussions | 23:20 |
| aspiers | IMHO, although probably I shouldn't be speculating about that on this public channel, oh well ;-) | 23:20 |
| persia | public and perpetually logged | 23:21 |
| krotscheck | Meh, technically we should be talking about this in #openstack-social anyway | 23:21 |
| aspiers | haha, thanks for the reminder | 23:21 |
| aspiers | true | 23:21 |
| Zara | it made my evening more entertaining :) | 23:21 |
| aspiers | I didn't even know about that channel | 23:21 |
| krotscheck | Quick, say something about javascript to feel like we're contributing! | 23:21 |
| krotscheck | Urm, y'all should move to Typescript, and use the angular/cli as your build system. | 23:21 |
| persia | Javascript framework churn seems to have decreased over the past couple years, making it easier to maintain stable systems with javascript | 23:22 |
| krotscheck | Oh, and ditch npm for yarn. The latter's deterministic vis-a-vis dependencies. | 23:22 |
| Zara | we still need to get off angular 1 someday | 23:22 |
| aspiers | OK, here's some JS for you: | 23:22 |
| krotscheck | persia: I... yeah, I guess that's right. Now it's Angular, React, Whatever-Jehuda's-Baby-Is-These-Days, and "Everyone else" | 23:22 |
| aspiers | console.log("Come and work for SUSE! https://jobs.suse.com/search-jobs/openstack/ and email openstack@adamspiers.org for confidential discussions"); | 23:22 |
| aspiers | ;-) OK, I'll shut up now | 23:22 |
| Zara | :) | 23:23 |
| aspiers | except for Storyboard-related stuff now anyway | 23:23 |
| krotscheck | aspiers: If I do, I'll be sending my resume through cmurphy, I already promised her the referral bonus :) | 23:23 |
| aspiers | lol | 23:23 |
| aspiers | I'm sure she deserves it | 23:23 |
| krotscheck | She's eye-blindingly smart. Yes. | 23:24 |
| aspiers | (BTW I don't know where any of you work, so this can't be counted as attempted poaching) | 23:24 |
| aspiers | cmurphy is awesome | 23:24 |
| krotscheck | (Not certain why that metaphor came out that way, but I'll stick with it) | 23:24 |
| * aspiers goes back to submitting stories | 23:24 | |
| * SotK catches up on backscroll | 23:41 | |
| aspiers | SotK: sorry about that ;-) | 23:41 |
| SotK | no problem, its nice to see such interest :) | 23:41 |
| SotK | afaik the requirement of >0 tasks per story was because story state is derived from tasks, and the webclient makes it difficult to find stories with no status or related projects (which also come from tasks) | 23:42 |
| SotK | it is possible to use the api to create a taskless story, so I think counting this as a UI bug is valid | 23:42 |
| SotK | the UI in https://review.openstack.org/#/c/526219/ doesn't have the task auto-fill behaviour, but it does still require at least one task | 23:43 |
| aspiers | I see, thanks | 23:43 |
| persia | Interesting use case for taskless stories is for folk to put together a feature description when they don't know the relevant projects, and then flesh it out over time, although that might require cultural changes about how we consider "stories" vs. "issues". | 23:44 |
| persia | Excellent side effect is that it makes the story effectively private to the creator (or those to whom it is explicitly shared) until it starts to accumulate tasks. | 23:45 |
| aspiers | exactly! | 23:46 |
| SotK | also, +1 for filing stories being good | 23:46 |
| SotK | persia: it wouldn't be safe to use that as an expectation of privacy really, GET /v1/stories would show them all | 23:49 |
| persia | I wasn't thinking "private" in the sense of "others can't see" (there's a flag for that), but rather in terms of signal/noise ratio for folk prioritising work for implementors. | 23:49 |
| persia | One can spend a fair bit of time working up a useful feature description, then add tasks to expose it to prioritisers. | 23:50 |
| persia | With a task requirement, the bar for making the story good enough to be comprehensible to others the first time is higher. | 23:50 |
| persia | Culturally, we tend to use this bar to reduce the number of annoying issues, but that may not always be the best solution. | 23:51 |
| persia | Mind you, we also use other bars: consider all the projects that start up new bugzilla installs in any given year: some of that just has to be to make sure that folk who don't know bugzilla can't file bugs (and at least one larger project uses bugzilla as the place for "triaged" bugs, with an entirely other system exposed to end users, although both allow self-signup and public view) | 23:52 |
| SotK | yeah, that does make sense | 23:56 |
| SotK | though I worry about a risk of people not familiar with sb just creating taskless stories leaving triagers to sift through a mess | 23:57 |
| SotK | perhaps that is something that can be resolved with good UI though | 23:57 |
| persia | I suspect that taskless stories will be invitisble to all but the most motivated of triagers | 23:59 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!