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
|
---
title: "Call for Participation (3)"
date: "2018-12-04T18:42:06"
tags: [ "linux", " open source", " programming", " rust", " software", " tools", " imag" ]
---
This is the third call for participation for the imag project.
<hr>
# How can I contribute?
There are several ways to contribute. The most important thing right
now is to get tools (we call them "modules") implemented. In the sections
below I list a few things we do not have in the imag ecosystem but would
really love to have, for example an email tool or a health tracker!
But you can also contribute by testing out imag and reporting your
experiences. If you find bugs (and trust me - there _are_ bugs) report them!
Report how you use imag and what you think could be improved (docs of course).
Also request features, request modules, request the hell out of me - or even
better: Contribute code!
Contributions (patches, questions, issues/bug reports) can be filed via the
[mailinglist](/mailinglist).
<hr>
## Debugging output
**Complexity: low, Effort: low**
The imag codebase contains a lot of `debug!()` statements. But it is not enough.
Sometimes even, the codebase has `debug!()` statements where it should have
`trace!()` statements.
The general rule is: Use `debug!()` for telling what is done, use `trace!()` for
show details, variables, what exact functions are called, etc.
There cannot be enough `trace!()` statements in the codebase!
## Replace is-match with matches
**Complexity: low, Effort: low**
The `is-match` crate can be deprecated in favour of the `matches` crate. That
would be a nice thing to have.
<!-- Old entries, still valid and possibly rewritten text: -->
## imag ecosystem improvements
Some stuff needs to be improved in the general imag ecosystem.
* Porting the whole ecosystem to use "impl-trait", remove all unneeded
iterator types.
* Revisiting the implementation of the bookmark library
* Revisiting the implementation of the habit library
## imag-mail
**Complexity: medium, Effort: medium**
Did you ever wanted to implement your own commandline email client? With the
imag project, you get the chance!
Of course, there are already some thoughts on how I want the `imag-mail`
command to behave like, but I'm open to discussions! Reach out to me to get
some details (or, even better: start a discussion on the mailinglist)!
## imag-health
**Complexity: medium, Effort: medium**
Did you ever wanted to implement your own commandline health/workout/diet
tracker? With the imag project, you get the chance!
I do not have any idea how such a tool would work like, so I'm completely open
to ideas and discussion about this! Feel free to reach out via the mailinglist!
## imag-todo
**Complexity: medium, Effort: medium**
(Needs reimplementation)
Right now, `imag-todo` is rather minimal. It is actually not a todo-tracker,
but a way of integrating "taskwarrior" into imag.
I would like that to change. imag should implement its own todo-tool and
taskwarrior (and todotxt) should be possible to integrate or to import (and
maybe even export).
Crates for taskwarrior interaction and todotxt interaction are available in
the rust ecosystem.
## Update dependencies
**Complexity: medium, Effort: medium**
Updating dependencies of imag is always a task.
Right now we have one dependency that is a little bit more complex to update:
The `imag-ids` command uses `nom` for parsing `where`-clauses, but the
dependency is outdated. Updating the dependency could be non-trivial as `nom`
gets updated in a major version (`3.*` -> `0.4`).
Also, the whole "where"-clause syntax could be reevaluated and even checked
whether it is actually necessary. Maybe it is more convenient to offer imag
commands that filter rather than having a DSL for that.
## Port Documentation to asciidoc?
**Complexity: low, Effort: low**
I guess porting the documentation to asciidoc would be a really neat thing.
Also (of course) the documentation needs an update. Which open source project
does not need this, really?
|
