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
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
|
#
msgid ""
msgstr ""
msgid "title: DIY an offline bug tracker with text files, Git and email"
msgstr ""
msgid "date: 2020-11-07"
msgstr ""
msgid "layout: post"
msgstr ""
msgid "lang: en"
msgstr ""
msgid "ref: diy-an-offline-bug-tracker-with-text-files-git-and-email"
msgstr ""
msgid ""
"When [push comes to "
"shove](https://github.com/github/dmca/blob/master/2020/10/2020-10-23-RIAA.md),"
" the operational aspects of governance of a software project matter a lot. "
"And everybody likes to chime in with their alternative of how to avoid "
"single points of failure in project governance, just like I'm doing right "
"now."
msgstr ""
msgid "The most valuable assets of a project are:"
msgstr ""
msgid "source code"
msgstr ""
msgid "discussions"
msgstr ""
msgid "documentation"
msgstr ""
msgid "builds"
msgstr ""
msgid "tasks and bugs"
msgstr ""
msgid ""
"For **source code**, Git and other DVCS solve that already: everybody gets a"
" full copy of the entire source code."
msgstr ""
msgid ""
"If your code forge is compromised, moving it to a new one takes a couple of "
"minutes, if there isn't a secondary remote serving as mirror already. In "
"this case, no action is required."
msgstr ""
msgid ""
"If you're having your **discussions** by email, \"[taking this archive "
"somewhere else and carrying on is "
"effortless](https://sourcehut.org/blog/2020-10-29-how-mailing-lists-prevent-"
"censorship/)\"."
msgstr ""
msgid ""
"Besides, make sure to backup archives of past discussions so that the "
"history is also preserved when this migration happens."
msgstr ""
msgid ""
"The **documentation** should [live inside the repository "
"itself](https://podcast.writethedocs.org/2017/01/25/episode-3-trends/)[^writethedocs-"
"in-repo], so that not only it gets first class treatment, but also gets "
"distributed to everybody too. Migrating the code to a new forge already "
"migrates the documentation with it."
msgstr ""
msgid ""
"[^writethedocs-in-repo]: Described as \"the ultimate marriage of the two\". "
"Starts at time 31:50."
msgstr ""
msgid ""
"As long as you keep the **builds** vendor neutral, the migration should only"
" involve adapting how you call your `tests.sh` from the format of "
"`provider-1.yml` uses to the format that `provider-2.yml` accepts. It isn't "
"valuable to carry the build history with the project, as this data quickly "
"decays in value as weeks and months go by."
msgstr ""
msgid ""
"But for **tasks and bugs** many rely on a vendor-specific service, where you"
" register and manage those issues via a web browser. Some provide an "
"[interface for interacting via email](https://man.sr.ht/todo.sr.ht/#email-"
"access) or an API for [bridging local bugs with vendor-specific "
"services](https://github.com/MichaelMure/git-bug#bridges). But they're all "
"layers around the service, that disguises it as being a central point of "
"failure, which when compromised would lead to data loss. When push comes to "
"shove, you'd loose data."
msgstr ""
msgid "Alternative: text files, Git and email"
msgstr ""
msgid ""
"Why not do the same as documentation, and move tasks and bugs into the "
"repository itself?"
msgstr ""
msgid ""
"It requires no extra tool to be installed, and fits right in the already "
"existing workflow for source code and documentation."
msgstr ""
msgid ""
"Any issues discussions are done in the mailing list, and a reference to a "
"discussion could be added to the ticket itself later on. External "
"contributors can file tickets by sending a patch."
msgstr ""
msgid ""
"The good thing about this solution is that it works for 99% of projects out "
"there."
msgstr ""
msgid ""
"For the other 1%, having Fossil's \"[tickets](https://fossil-"
"scm.org/home/doc/trunk/www/bugtheory.wiki)\" could be an alternative, but "
"you may not want to migrate your project to Fossil to get those niceties."
msgstr ""
msgid ""
"Even though I keep a `TODOs.org` file on the main branch, you can have a "
"`tasks` branch with a `task-n.md` file for each task, or any other way you "
"like."
msgstr ""
msgid ""
"These tools are familiar enough that you can adjust it to fit your workflow."
msgstr ""
msgid ""
"I like to keep a "
"[`TODOs.org`](https://git.euandreh.xyz/mediator/tree/TODOs.org) file at the "
"repository top-level, with two relevant sections: \"tasks\" and \"bugs\". "
"Then when building the documentation I'll just [generate an HTML file from "
"it](https://git.euandreh.xyz/mediator/tree/scripts/build-"
"site.sh?id=db4a727bc24b54b50158827b34502de21dbf8948#n14), and "
"[publish](https://mediator.euandreh.xyz/tasks-and-bugs.html) it alongside "
"the static website. All that is done on the main branch."
msgstr ""
#~ msgid ""
#~ "I like to keep a "
#~ "[`TODOs.org`](https://git.euandreh.xyz/mediator/tree/TODOs.org?id=110c0af4ef53faf6e1ebe87905ce16766548607e)"
#~ " file at the repository top-level, with two relevant sections: \"tasks\" and"
#~ " \"bugs\". Then when building the documentation I'll just [generate an HTML "
#~ "file from it](https://git.euandreh.xyz/mediator/tree/scripts/build-"
#~ "site.sh?id=db4a727bc24b54b50158827b34502de21dbf8948#n14), and "
#~ "[publish](https://mediator.euandreh.xyz/tasks-and-bugs.html) it alongside "
#~ "the static website. All that is done on the main branch."
#~ msgstr ""
|
