-
Notifications
You must be signed in to change notification settings - Fork 38
Use labels (connected graph) instead of tree for items #183
Comments
Sorry I haven't gotten to this. I am on haitus from this project for a little while while I help with the rust-impl period. I'm collecting some thoughts on what I want to do for 2.0 and will consider this then. |
I'm not sure I follow. Let me make sure I understand your proposal. As I see it there are two of them: Feature1: add the ability to add "tags"This is something I would use #107 for. One of the design requirements of artifact is that it is very slow to add features and I am basically unwilling to add additional attributes at all (but would allow a plugin to do so). Feature 2: use pijul to track progressI'm a little confused about the implementation here. I'm not sure why Pijul could provide any kind of automated way of detecting that a requirement changed (other than the way other version control systems already do). Also, I am unwilling to tie artifact to any particular vcs system Related: I have another design I've been throwing around that I've been thinking could help address this. It would allow you to define "mini specifications" inside the text block of SPC or TST types that can link to source code. So you could do something like this:
Each of these "sub-parts" could then be linked in code using The sub-parts would then be used for also calculating the completeness of the item. In the web-ui, you would be able to click to the line of code that the linked items are at. This would also be useful when combined with #158, as you could create a graph that also links to code. |
I opened #186 to track the second feature I proposed. |
Since there has not been commentary on this for about two weeks I am closing. Feel free to reopen if you have additional comments. |
I’ll start out this issue philosophically, so let’s discuss a bit.
Suppose a requirement has both significant security and performance reasons. Currently with Artifact it seems you would have to file them as REQ-security-... or REQ-performance-.... This isn't really optimal because you cannot immediately track down all open security or performance issues this way.
Artifact could create unique value here by providing a means to relate ‘items of a Kanban-board like nature’ (i.e. issues, see e.g. GitLab), organized with tags, to the actual source code. This representation of the requirements, implementations and tests would no longer necessarily be a tree though.
I have an alternative proposal as well. References to Pijul patches could be a better way to track progress than annotations in comments, how Artifact currently works. ‘Progress’ could be defined to mean anything from implementing and testing formal requirements to resolved issues on a Kanban board. Why is it better? Since with Artifact, a line asserting that the following(?) code implements a certain requirement only remains connected to the actual code through discipline of the programmer. If the code is changed meaningfully so that the requirement or even specification is no longer met, it’ll be hard to catch that. If you miss it as manager, then the Artifact overview won't be accurate anymore. With Pijul patches, it is always possible to detect how source code that met a requirement earlier is affected in the event another patch is merged later.
The text was updated successfully, but these errors were encountered: