blob: 4b7dd354e0dd8884f54ad861a35cbfa6781c3de1 (
plain)
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
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
|
# Designing an issue tracker on gemini
Why do we want to consolidate issue trackers and kanban boards using gemini+git? Several reasons:
* Get rid of web service dependencies (in our case github issue tracker and trello kanban)
* Track issues in text files - edit with your favourite editor
* Provide our own viewer - the github issue tracker and trello boards are not very configurable, e.g. what to do with a stale issue - why do we need to run an action?
* Own the trackers
Now the last one may be the most important. Currently anyone can post on our issue trackers and you get issues like
=> https://github.com/genetics-statistics/GEMMA/issues/250 Not read the docs example
Where someone posts who has not read the manual (sorry for the exposition). Or from another project I am involved in
=> https://github.com/vcflib/vcflib/issues/206 Rude example
where someone is very rude and lacks obvious knowledge about the free software effort (not sorry about exposing this one - luckily this is a small minority). With our new gemini tracker we own the issue reporting space. People can submit a request to report an issue and we can decide whether it belongs there or not. Takes a little more effort on the submitter too! But not too much - you have to know git or fork and clone in github. The downside may be that some normal users feel they need to do too much. In that case send an E-mail instead - that is what they do anyway. We can file E-mails as issues ourselves.
## Example
I added a first issue here:
=> https://github.com/genenetwork/gn-gemtext-threads/blob/main/issues/database-not-responding.gmi
## Process
I am thinking we just use git to pull out dates and people contributions (pjotrp wrote ...) for display in a document/web page.
Assuming people add to the doc at the bottom that should not be too hard.
At the top we could add tags:
* assigned: pjotrp, zachs
* keywords: critical bug, in progress
* milestone: 1.1
Which we can use to generate lists of links.
Make sense?
For the kanban board we can simply use the keywords. Override/add with a separate
* kanban: Brain storm
Keywords are flexible, but common wons are
* request
* bug
* critical bug
* enhancement
* in progress
* testing
* later
* documentation
* help wanted
* closed
the keyword statement may have aliases, such as tag and kanban. To undo a keyword simply remove them from the file.
Can't think of anything more to add to make it really useful :)
## Tracking information
Git can do all of that. A viewer may benefit from serial git information, therefore it is recommended to add information to the end of the file.
## Closing issues
Moving an issue file will disconnect the git record. Therefore simple add
* tag: closed
## Converting
### Converting issues from a github issue tracker
=> https://github.com/mattduck/gh2md Github to markdown dump
|
