1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
|
# A linter for gnbug
## Tags
* type: feature-request
* keywords: gnbug, linter, tissue
* assigned: ??
* priority: low
* status: under discussion
## Description
Should gnbug have a linter?
For example, If a user forgets to add a tag or some other syntax that we want them
to add then the linter reminds them to add more info, tags, etc.
Or, maybe we want to check that the user does not add a tag that we don't want to
support.
I am not sure. Pjotr is of the philosophy that we should keep the text as unstructured and unrestrictive as possible, and I agree with this philosophy. Linters are likely to annoy users more than help them. They might discourage casual use of the issue tracker. Especially with tags, we don't really want to restrict the user from coming up with new tags.
WDYT? Am I missing some scenario where the linter could be essential?
Nope, it was just something I thought could be convenient if we wanted to restrict
the format for tags, etc...
If we'd like to "keep the text as unstructured and unrestrictive as possible" I'm
fine with that too.
I was just worried about using "invalid" tags. Now, I know it's ok :)
### 2022-03-14
I am thinking tissue (formerly gnbug) should deal with a list of tags of the form:
```
* key: value[, value, ...]
```
and each instance of the issue tracker can have some config file that defines, among other things:
* what tags to display
* colouring of said tags
* maybe what tags to allow (for those that need to restrict allowed tags)
The tags could be parsed into a hashmap or an associative list, or any other similarly useful datatype, from which the values would be read for display.
Tissue could determine what the context is (CLI, web, etc) and using the config, figure out what tags to display and how
|
