Skip to content
This repository has been archived by the owner on Oct 25, 2021. It is now read-only.

Use labels (connected graph) instead of tree for items #183

Closed
sanmai-NL opened this issue Oct 5, 2017 · 4 comments
Closed

Use labels (connected graph) instead of tree for items #183

sanmai-NL opened this issue Oct 5, 2017 · 4 comments

Comments

@sanmai-NL
Copy link

sanmai-NL commented Oct 5, 2017

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.

@vitiral
Copy link
Owner

vitiral commented Oct 18, 2017

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.

@vitiral
Copy link
Owner

vitiral commented Oct 21, 2017

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 progress

I'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:

[SPC-foo]
text = '''
This has multiple parts of implementation:
- [[.input]]: take the input
- [[.process]]: process the input
- [[.log]] log the result
'''

Each of these "sub-parts" could then be linked in code using #SPC-foo.input, #SPC-foo.process, etc. Since the . character is currently illegal, there is no possibility of overlap.

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.

@vitiral
Copy link
Owner

vitiral commented Oct 22, 2017

I opened #186 to track the second feature I proposed.

@vitiral
Copy link
Owner

vitiral commented Nov 4, 2017

Since there has not been commentary on this for about two weeks I am closing. Feel free to reopen if you have additional comments.

@vitiral vitiral closed this as completed Nov 4, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants