| *** brlogger (~supybot@185.43.218.182) has quit (Read error: Connection reset by peer) | 00:09 | |
| *** brlogger (~supybot@185.43.218.182) has joined #trustable | 00:11 | |
| *** brlogger (~supybot@185.43.218.182) has quit (Read error: Connection reset by peer) | 00:25 | |
| *** brlogger (~supybot@185.43.218.182) has joined #trustable | 00:25 | |
| *** brlogger (~supybot@185.43.218.182) has quit (Read error: Connection reset by peer) | 00:31 | |
| *** brlogger (~supybot@185.43.218.182) has joined #trustable | 00:33 | |
| *** brlogger (~supybot@185.43.218.182) has quit (Read error: Connection reset by peer) | 00:37 | |
| *** brlogger (~supybot@185.43.218.182) has joined #trustable | 00:38 | |
| *** brlogger (~supybot@185.43.218.182) has quit (Read error: Connection reset by peer) | 00:40 | |
| *** brlogger (~supybot@185.43.218.182) has joined #trustable | 00:41 | |
| *** brlogger (~supybot@185.43.218.182) has quit (Read error: Connection reset by peer) | 00:43 | |
| *** brlogger (~supybot@185.43.218.182) has joined #trustable | 00:43 | |
| *** brlogger (~supybot@185.43.218.182) has quit (Read error: Connection reset by peer) | 01:04 | |
| *** brlogger (~supybot@185.43.218.182) has joined #trustable | 01:06 | |
| => Netsplit between *.net and *.split ended. Users joined: paulsherwood | 01:15 | |
| *** brlogger (~supybot@185.43.218.182) has quit (Read error: Connection reset by peer) | 01:15 | |
| *** brlogger (~supybot@185.43.218.182) has joined #trustable | 01:16 | |
| *** brlogger (~supybot@185.43.218.182) has quit (Read error: Connection reset by peer) | 01:21 | |
| *** brlogger (~supybot@185.43.218.182) has joined #trustable | 01:21 | |
| *** brlogger (~supybot@185.43.218.182) has quit (Read error: Connection reset by peer) | 01:39 | |
| *** brlogger (~supybot@185.43.218.182) has joined #trustable | 01:41 | |
| *** brlogger (~supybot@185.43.218.182) has quit (Read error: Connection reset by peer) | 01:45 | |
| *** brlogger (~supybot@185.43.218.182) has joined #trustable | 01:45 | |
| *** brlogger (~supybot@185.43.218.182) has quit (Read error: Connection reset by peer) | 02:01 | |
| *** brlogger (~supybot@185.43.218.182) has joined #trustable | 02:05 | |
| *** brlogger (~supybot@185.43.218.182) has quit (Read error: Connection reset by peer) | 02:13 | |
| *** brlogger (~supybot@185.43.218.182) has joined #trustable | 02:13 | |
| *** brlogger (~supybot@185.43.218.182) has quit (Read error: Connection reset by peer) | 02:28 | |
| *** brlogger (~supybot@185.43.218.182) has joined #trustable | 02:29 | |
| *** brlogger (~supybot@185.43.218.182) has quit (Read error: Connection reset by peer) | 02:31 | |
| *** brlogger (~supybot@185.43.218.182) has joined #trustable | 02:32 | |
| *** brlogger (~supybot@185.43.218.182) has quit (Read error: Connection reset by peer) | 02:32 | |
| *** brlogger (~supybot@185.43.218.182) has joined #trustable | 02:33 | |
| *** brlogger (~supybot@185.43.218.182) has quit (Read error: Connection reset by peer) | 02:52 | |
| *** brlogger (~supybot@185.43.218.182) has joined #trustable | 02:53 | |
| *** brlogger (~supybot@185.43.218.182) has quit (Read error: Connection reset by peer) | 02:55 | |
| *** brlogger (~supybot@185.43.218.182) has joined #trustable | 02:55 | |
| *** brlogger (~supybot@185.43.218.182) has quit (Read error: Connection reset by peer) | 03:01 | |
| *** brlogger (~supybot@185.43.218.182) has joined #trustable | 03:02 | |
| *** brlogger (~supybot@185.43.218.182) has quit (Read error: Connection reset by peer) | 03:12 | |
| *** brlogger (~supybot@185.43.218.182) has joined #trustable | 03:14 | |
| *** brlogger (~supybot@185.43.218.182) has quit (Read error: Connection reset by peer) | 03:18 | |
| *** brlogger (~supybot@185.43.218.182) has joined #trustable | 03:18 | |
| *** brlogger (~supybot@185.43.218.182) has quit (Read error: Connection reset by peer) | 03:20 | |
| *** brlogger (~supybot@185.43.218.182) has joined #trustable | 03:23 | |
| *** brlogger (~supybot@185.43.218.182) has quit (Read error: Connection reset by peer) | 03:23 | |
| *** brlogger (~supybot@185.43.218.182) has joined #trustable | 03:23 | |
| *** brlogger (~supybot@185.43.218.182) has quit (Read error: Connection reset by peer) | 03:36 | |
| *** brlogger (~supybot@185.43.218.182) has joined #trustable | 03:38 | |
| *** brlogger (~supybot@185.43.218.182) has quit (Read error: Connection reset by peer) | 03:39 | |
| *** brlogger (~supybot@185.43.218.182) has joined #trustable | 03:40 | |
| *** brlogger (~supybot@185.43.218.182) has quit (Read error: Connection reset by peer) | 03:46 | |
| *** brlogger (~supybot@185.43.218.182) has joined #trustable | 03:48 | |
| *** brlogger (~supybot@185.43.218.182) has quit (Read error: Connection reset by peer) | 04:04 | |
| *** brlogger (~supybot@185.43.218.182) has joined #trustable | 04:04 | |
| *** brlogger (~supybot@185.43.218.182) has quit (Read error: Connection reset by peer) | 04:04 | |
| *** brlogger (~supybot@185.43.218.182) has joined #trustable | 04:04 | |
| *** brlogger (~supybot@185.43.218.182) has quit (Read error: Connection reset by peer) | 04:04 | |
| *** brlogger (~supybot@185.43.218.182) has joined #trustable | 04:05 | |
| *** brlogger (~supybot@185.43.218.182) has quit (Read error: Connection reset by peer) | 04:19 | |
| *** brlogger (~supybot@185.43.218.182) has joined #trustable | 04:21 | |
| *** brlogger (~supybot@185.43.218.182) has quit (Read error: Connection reset by peer) | 04:49 | |
| *** brlogger (~supybot@185.43.218.182) has joined #trustable | 04:51 | |
| *** brlogger (~supybot@185.43.218.182) has quit (Read error: Connection reset by peer) | 05:07 | |
| *** brlogger (~supybot@185.43.218.182) has joined #trustable | 05:09 | |
| *** brlogger (~supybot@185.43.218.182) has quit (Read error: Connection reset by peer) | 05:11 | |
| *** brlogger (~supybot@185.43.218.182) has joined #trustable | 05:12 | |
| *** brlogger (~supybot@185.43.218.182) has quit (Read error: Connection reset by peer) | 05:13 | |
| *** brlogger (~supybot@185.43.218.182) has joined #trustable | 05:14 | |
| *** brlogger (~supybot@185.43.218.182) has quit (Read error: Connection reset by peer) | 05:30 | |
| *** brlogger (~supybot@185.43.218.182) has joined #trustable | 05:31 | |
| *** brlogger (~supybot@185.43.218.182) has quit (Read error: Connection reset by peer) | 06:05 | |
| *** brlogger (~supybot@185.43.218.182) has joined #trustable | 06:07 | |
| *** brlogger (~supybot@185.43.218.182) has quit (Read error: Connection reset by peer) | 06:27 | |
| *** brlogger (~supybot@185.43.218.182) has joined #trustable | 06:29 | |
| *** AlisonChaiken (~AlisonCha@173-228-89-193.dsl.static.fusionbroadband.com) has joined #trustable | 06:38 | |
| *** brlogger (~supybot@185.43.218.182) has quit (Read error: Connection reset by peer) | 06:53 | |
| *** brlogger (~supybot@185.43.218.182) has joined #trustable | 06:55 | |
| *** brlogger (~supybot@185.43.218.182) has quit (Read error: Connection reset by peer) | 07:25 | |
| *** brlogger (~supybot@185.43.218.182) has joined #trustable | 07:27 | |
| *** brlogger (~supybot@185.43.218.182) has quit (Read error: Connection reset by peer) | 07:31 | |
| *** brlogger (~supybot@185.43.218.182) has joined #trustable | 07:31 | |
| *** brlogger (~supybot@185.43.218.182) has quit (Read error: Connection reset by peer) | 07:58 | |
| *** brlogger (~supybot@185.43.218.182) has joined #trustable | 07:59 | |
| *** brlogger (~supybot@185.43.218.182) has quit (Read error: Connection reset by peer) | 08:09 | |
| *** brlogger (~supybot@185.43.218.182) has joined #trustable | 08:10 | |
| *** brlogger (~supybot@185.43.218.182) has quit (Read error: Connection reset by peer) | 08:24 | |
| *** brlogger (~supybot@185.43.218.182) has joined #trustable | 08:25 | |
| *** tiagogomes (~tiagogome@82-70-136-246.dsl.in-addr.zen.co.uk) has quit (Ping timeout: 248 seconds) | 08:25 | |
| *** sambishop (~sambishop@82-70-136-246.dsl.in-addr.zen.co.uk) has quit (Ping timeout: 245 seconds) | 08:25 | |
| <= Netsplit between *.net and *.split. Users quit: rjek, andrewleeming_, persia, dabukalam | 08:31 | |
| *** ctbruce (~bruceunde@82-70-136-246.dsl.in-addr.zen.co.uk) has joined #trustable | 08:34 | |
| *** sambishop (~sambishop@82-70-136-246.dsl.in-addr.zen.co.uk) has joined #trustable | 08:37 | |
| => Netsplit between *.net and *.split ended. Users joined: rjek, andrewleeming_, persia, dabukalam | 08:38 | |
| *** tiagogomes (~tiagogome@82-70-136-246.dsl.in-addr.zen.co.uk) has joined #trustable | 08:38 | |
| *** brlogger (~supybot@185.43.218.182) has quit (Read error: Connection reset by peer) | 08:39 | |
| *** brlogger (~supybot@185.43.218.182) has joined #trustable | 08:39 | |
| *** toscalix (~toscalix@90.170.203.139) has joined #trustable | 08:46 | |
| *** brlogger (~supybot@185.43.218.182) has quit (Read error: Connection reset by peer) | 08:59 | |
| *** brlogger (~supybot@185.43.218.182) has joined #trustable | 08:59 | |
| *** brlogger (~supybot@185.43.218.182) has quit (Read error: Connection reset by peer) | 08:59 | |
| *** brlogger (~supybot@185.43.218.182) has joined #trustable | 09:00 | |
| *** brlogger (~supybot@185.43.218.182) has quit (Read error: Connection reset by peer) | 09:01 | |
| *** brlogger (~supybot@185.43.218.182) has joined #trustable | 09:01 | |
| *** brlogger (~supybot@185.43.218.182) has quit (Read error: Connection reset by peer) | 09:24 | |
| *** brlogger (~supybot@185.43.218.182) has joined #trustable | 09:24 | |
| *** laurenceurhegyi (~laurenceu@82-70-136-246.dsl.in-addr.zen.co.uk) has joined #trustable | 09:26 | |
| *** brlogger (~supybot@185.43.218.182) has quit (Read error: Connection reset by peer) | 09:38 | |
| *** brlogger (~supybot@185.43.218.182) has joined #trustable | 09:39 | |
| *** brlogger (~supybot@185.43.218.182) has quit (Read error: Connection reset by peer) | 09:39 | |
| *** brlogger (~supybot@185.43.218.182) has joined #trustable | 09:39 | |
| *** brlogger (~supybot@185.43.218.182) has quit (Read error: Connection reset by peer) | 10:20 | |
| *** brlogger (~supybot@185.43.218.182) has joined #trustable | 10:21 | |
| *** brlogger (~supybot@185.43.218.182) has quit (Read error: Connection reset by peer) | 10:41 | |
| *** sambishop (~sambishop@82-70-136-246.dsl.in-addr.zen.co.uk) has quit (Ping timeout: 240 seconds) | 10:42 | |
| *** brlogger (~supybot@185.43.218.182) has joined #trustable | 10:45 | |
| mdunford | brlogger, plz stahp | 10:52 |
|---|---|---|
| brlogger | mdunford: Error: "plz" is not a valid command. | 10:52 |
| rjek | haha | 10:52 |
| chrispolin | Hahaha | 10:53 |
| *** brlogger (~supybot@185.43.218.182) has quit (Read error: Connection reset by peer) | 10:53 | |
| *** brlogger (~supybot@185.43.218.182) has joined #trustable | 10:54 | |
| pedroalvarez | right... I'll make it stop | 10:54 |
| *** brlogger (~supybot@185.43.218.182) has quit (Remote host closed the connection) | 10:54 | |
| -*- mdunford shakes fist | 10:57 | |
| *** sambishop (~sambishop@82-70-136-246.dsl.in-addr.zen.co.uk) has joined #trustable | 10:57 | |
| jmacs | pedroalvarez has been working pretty hard to get brlogger working; give it time | 10:58 |
| chrispolin | Just disable alerts for joins/leaves. | 10:58 |
| *** brlogger (~supybot@185.43.218.182) has joined #trustable | 11:00 | |
| *** brlogger (~supybot@185.43.218.182) has quit (Remote host closed the connection) | 11:03 | |
| *** sambishop (~sambishop@82-70-136-246.dsl.in-addr.zen.co.uk) has quit (Ping timeout: 246 seconds) | 11:08 | |
| laurenceurhegyi | So, we'd set ourselves the deadline of posting the Trustable Software Workflow to the mailing list this week. It's clear that the user stories are hugely useful and should shape the design of the workflow. | 11:27 |
| laurenceurhegyi | However it's also clear that if we want to include the user stories then we won't be able to post the TSW today. | 11:27 |
| laurenceurhegyi | (I imagine that they'd take us the best part of a week, as we'd write them and then amend the TWS a fair bit as a result) | 11:28 |
| laurenceurhegyi | So I think we can either a) wait, get it right, post to the list next week. | 11:29 |
| laurenceurhegyi | Or b) post today and mention the user stories we are creating and the fact that we are trying to break it by creating these edge cases | 11:29 |
| laurenceurhegyi | As much as I don't like missing deadlines (even self-imposed ones) I think b) is probably the more sensible option. | 11:30 |
| chrispolin | a) ? | 11:30 |
| laurenceurhegyi | Sorry, A) | 11:31 |
| laurenceurhegyi | thanks chrispolin! | 11:31 |
| -*- paulsherwood votes for b) | 11:45 | |
| paulsherwood | on the basis of commit early and often | 11:45 |
| paulsherwood | you have a chance to get more feedback this way | 11:45 |
| paulsherwood | it's rarely better to turn up with big lumps of surprise work, ime | 11:46 |
| laurenceurhegyi | that's also true, yes - let's go with b) then. chrispolin? | 11:49 |
| chrispolin | A fair point. My only concern is that if it is presented with a few flaws that are easily ironed out, they'll dominate the discussion and the actual probing questions that we need to hear will take a back seat. | 11:49 |
| chrispolin | easily ironed out after the User Stories have exposed them, I should say. | 11:50 |
| chrispolin | But if you feel that the benefit of getting it out there outweighs this concern, then I'm happy to put it back together and post it this afternoon. | 11:53 |
| -*- paulsherwood doesn't mind either way, really | 11:53 | |
| *** sambishop (~sambishop@82-70-136-246.dsl.in-addr.zen.co.uk) has joined #trustable | 12:01 | |
| laurenceurhegyi | chrispolin: my original thoughts when we discussed earlier were: there will *always* be something people pick up on, and we could tweak it forever and never get it posted if we have that concern. | 12:02 |
| chrispolin | That's true. Sure, I'll post to the mailing list this afternoon then so. | 12:04 |
| laurenceurhegyi | So I'd like to post it, mention the user stories, then when they're done, post the updates with accompanying rationale | 12:04 |
| laurenceurhegyi | Cool | 12:04 |
| *** laurenceurhegyi (~laurenceu@82-70-136-246.dsl.in-addr.zen.co.uk) has quit (Ping timeout: 248 seconds) | 13:10 | |
| *** laurenceurhegyi (~laurenceu@82-70-136-246.dsl.in-addr.zen.co.uk) has joined #trustable | 13:38 | |
| *** sambishop (~sambishop@82-70-136-246.dsl.in-addr.zen.co.uk) has quit (Ping timeout: 256 seconds) | 14:02 | |
| *** sambishop (~sambishop@82-70-136-246.dsl.in-addr.zen.co.uk) has joined #trustable | 14:17 | |
| *** sambishop (~sambishop@82-70-136-246.dsl.in-addr.zen.co.uk) has quit (Ping timeout: 258 seconds) | 15:06 | |
| persia | chrispolin: Did you think of any more stories? Do you mind if I take a first draft of writing the Persona YAML? | 15:27 |
| chrispolin | Hi persia, I keep coming up with new ones that turn out to be encapsulated by the ones you've posted lol. | 15:30 |
| chrispolin | Feel free. | 15:31 |
| persia | That builds my confidence :) In the process of drafting stories, we may expose more, but that can come later. | 15:32 |
| persia | One thought I had was that we might need John, a compliance validation engineer, who executes some complex (perhaps physical) validation that cannot sensibly be done for every potential patch (e.g. wind tunnel testing of yaw control automation for fixed-wing aircraft) | 15:34 |
| chrispolin | Does he differ significantly from Catherine the compliance officer? | 15:35 |
| persia | Depends on how they get fleshed out. I supposed Catherine would be responsible for compliance (such that she cared about new standards, reporting, etc.), and John would just perform the tests occasionally as part of a CD pipeline, reporting results to Catherine. | 15:36 |
| persia | Ernestine may also be interested in John's tests, but I don't imagine that the results would automatically feed back into the patch tracker, or that John would be testing anything that Catherine didn't believe was likely to be compliant. | 15:37 |
| persia | Maybe I'm breaking things down too much, and John should wait until we have a story that needs him. | 15:37 |
| chrispolin | I'd be inclined to agree, I'm not convinced that he isn't superfluous for the time being. | 15:38 |
| persia | Fair enough :) My first thought was that John was a user, who would report a bug, but if this works, there shouldn't be any bugs, so I changed him to do expensive testing in my head, but now I agree that this class of story should be covered by Catherine, perhaps with help from Franklin. | 15:42 |
| *** sambishop (~sambishop@82-70-136-246.dsl.in-addr.zen.co.uk) has joined #trustable | 15:42 | |
| *** laurenceurhegyi_ (~laurenceu@82-70-136-246.dsl.in-addr.zen.co.uk) has joined #trustable | 16:05 | |
| *** laurenceurhegyi (~laurenceu@82-70-136-246.dsl.in-addr.zen.co.uk) has left #trustable ("Leaving") | 16:06 | |
| - | laurenceurhegyi_ is now known as LaurenceUrhegyi | 16:07 |
| *** LaurenceUrhegyi (~laurenceu@82-70-136-246.dsl.in-addr.zen.co.uk) has left #trustable | 16:07 | |
| *** LaurenceUrhegyi (~laurenceu@82-70-136-246.dsl.in-addr.zen.co.uk) has joined #trustable | 16:07 | |
| *** ctbruce (~bruceunde@82-70-136-246.dsl.in-addr.zen.co.uk) has quit (Quit: Leaving) | 16:24 | |
| persia | Hrm. I thought consumption tooling wasn't important for an initial draft of YAML for the stories, but then I realised that it might. | 16:39 |
| persia | So, any given scenario has two different binary statuses, being whether it was (intended to be) implemented, and whether any given revision of the code happens to comply. | 16:40 |
| persia | In the schema I was using, whether something is intended to be implemented is encoded as a textual change to the requirements, which might not work for some workflows involving not changing requirements without certain levels of approvals. | 16:40 |
| persia | As this would require those same levels of approvals in order to indicate whether something had been implemented or not. | 16:41 |
| persia | So, unless anyone wants to debate the merits of various formats, I think I'll just use the following structure: | 16:41 |
| persia | A) directories named "personas" and "stories" | 16:42 |
| persia | B) "personas" contain one file for each persona, with "title", "kind: tag", and "description". | 16:42 |
| persia | C) "stories" contain one file for each story, with "title", "kind: requirement", "description", and "tags", where "tags" is a list of personas. | 16:43 |
| persia | Does anyone want to discuss alternate YAML structures? Alternately, does anyone see any issues with that as a first pass for the user stories? | 16:43 |
| chrispolin | It makes sense to me. | 16:45 |
| chrispolin | I've just updated the TSW on the wiki page (https://gitlab.com/trustable/overview/wikis/TrustableSoftwareWorkflow), if you're happy with it as a first pass I'll post it to the trustable mailing list as a RFC. | 16:50 |
| persia | Looks OK to me. I have some nitpicks, but only nitpicks. | 16:53 |
| chrispolin | Pick away, I'd like it to have as few nits as possible, so that the conversation is about the meat of the model. | 16:54 |
| persia | I think it should be shared widely, to get more feedback, even before any changes for my feedback, but I'll comment in detail anyway. | 16:54 |
| persia | Don't worry about that. Polishing something before sending for review tends to cause issues: one has no confirmation that one has the right structure, and the polished skin becomes harder to fix later. | 16:54 |
| persia | Some folk will pick at the edges, but I think most folk who care about this topic are going to be more interested in talking about the core struture, and willing to forgive details until there is wider consensus. | 16:55 |
| chrispolin | Sure. I'll email the list now then. | 16:56 |
| persia | Anyway, I still think the text implies a sequence of review (robot, then human), rather than a requirement that a set of reviews be made (human and robot). In other projects, I can think of several cases where the humans reviewed before the robots (especially for quick-fix patches that needed to land quickly). | 16:56 |
| chrispolin | Noted. | 16:57 |
| persia | The phrasing of the automated review is a little confusing to me, but it might just be me. That the "pre-determined rules" is encapsulated in the machine-readable text of the requirements and standards requires some prior knowledge. | 16:57 |
| persia | We never got around to the discussion of whether the CI and the Automerger were the same thing, but that the Automerger is submitting to testing and the CI not described as submitting to testing makes me wonder if the tests have already been run (although my prior knowledge lets me know that the pre-determined rules check is submitting to testing). | 16:59 |
| persia | The parenthetical comment in the CD paragraph seems to apply to the entire list of requirements, standards, submission data, and test results (whereas my prior knowledge suggests you only meant test results). I reocmmend changing the order so that the parenthetical comment appears in the middle of the list, for clarity. | 17:00 |
| persia | More complexly, I think we want to have the CI system generate candidate compliance documentation for every candidate revision, but that makes the diagram messy, and may make the workflow confusing to people consuming it the first time, so maybe doesn't belong in the text. | 17:01 |
| persia | Oh, and above all that, our diagram isn't actually compliant machine-readable UML (but I encourage you not to change that: I just want to keep it in mind, as I think the goal is to move towards a design that *is* compliant UML, so we can use it as a machine-readable description of the system, to check compliance) | 17:03 |
| chrispolin | Yeah, I think once we've got a bit of feedback and we're sure that the structure is as it should be, we can then fix that. | 17:11 |
| persia | I imagine this will go through many more revisions. | 17:13 |
| persia | Trying to compose the stories, I find that I'm having trouble with consistency. Unless you object, I think I'll try to compose them as an ongoing narrative, starting with one about Christine (to whom I want to grant a technical background) first working to encode a standard (working with Alice), followed by Hank working with Ernestine and Bob to encode some requirements, etc. | 17:15 |
| persia | Any suggestions on how to encode a summary of the overall narrative in Mustard? I'm thikning about maybe having a top-level document that references the specific user stories, or some such. | 17:17 |
| chrispolin | This may be better directed at jmacs, as he has more experience with Mustard schemas. | 17:18 |
| jmacs | Sorry, I've kind of tuned out of this channel while working on something else | 17:19 |
| jmacs | Is the narrative visible somewhere? | 17:20 |
| *** toscalix (~toscalix@90.170.203.139) has quit (Quit: Konversation terminated!) | 17:23 | |
| LaurenceUrhegyi | I too seem to have missed some context, as I disconnected and then connected to freenode via the bouncer. | 17:27 |
| persia | jmacs: It doesn't exist currently. My thought was that if I was writing a sequence of related stories, I would simultaneously write an overview document with quick descriptions (kind of like the old fashion of chapter heading abstracts). Each story is encoded as kind: requirement. I just don't know the right way to encode the overview. Is it "kind: project"? | 17:29 |
| -*- jmacs checks his notes | 17:30 | |
| persia | Do I need any special annotation to link to the specific requirements? | 17:31 |
| jmacs | persia: I would encode the overview as a kind: requirement as well. | 17:31 |
| jmacs | Then add the stories as requirements in the same yaml file, one level down from the overview | 17:32 |
| persia | I was writing the stories as one per file. | 17:33 |
| persia | With the expectation that scenarios would live one level down from those. | 17:33 |
| jmacs | I think you may be able to link hierarchical requirements in separate files, just by matching the names | 17:35 |
| jmacs | For example, one file containing an object called r/overview and several files containing objects called r/overview/foo | 17:36 |
| jmacs | r/overview/bar, etc | 17:36 |
| persia | Which field do you mean when you say "called"? Is that a filename? Is that title:? | 17:36 |
| jmacs | The key text in the yaml files, I think | 17:37 |
| jmacs | My memory of this is fuzzy | 17:37 |
| jmacs | Having checked... | 17:38 |
| jmacs | The path, filename and object name all form part of the name of an object in Mustard. | 17:39 |
| jmacs | A file called req/mason.yaml containing a key called 'cd-system' results in an object called "req/mason/cd-system" | 17:40 |
| jmacs | That object cd-system itself contains keys called kind, title, description and others | 17:40 |
| persia | Aha, so if I have stories/foo.yaml, then the overview would be in stories.yaml? | 17:41 |
| jmacs | I would guess that you could create a file called 'req.yaml' which contained a top-level object called 'mason/cd-system' with the same effect | 17:41 |
| jmacs | Mustard was not written by someone who shared my disdain for hierarchies | 17:42 |
| *** sambishop (~sambishop@82-70-136-246.dsl.in-addr.zen.co.uk) has quit (Ping timeout: 245 seconds) | 17:49 | |
| *** AlisonChaiken (~AlisonCha@173-228-89-193.dsl.static.fusionbroadband.com) has quit (Quit: Leaving) | 17:49 | |
| *** tiagogomes (~tiagogome@82-70-136-246.dsl.in-addr.zen.co.uk) has quit (Quit: Leaving) | 18:43 | |
| *** LaurenceUrhegyi (~laurenceu@82-70-136-246.dsl.in-addr.zen.co.uk) has quit (Quit: Leaving) | 18:51 | |
| *** AlisonChaiken (~alison@12.1.72.210) has joined #trustable | 19:20 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!