Add post: Call for Participation (1)

1 files changed, 248 insertions, 0 deletions

diff --git a/content/blog/2018-10-10-call-for-participation-1.md b/content/blog/2018-10-10-call-for-participation-1.md
new file mode 100644
index 0000000..37744a8
--- /dev/null
+++ b/content/blog/2018-10-10-call-for-participation-1.md
@@ -0,0 +1,248 @@
+---
+title: "Call for Participation (1)"
+date: "2018-10-10T08:42:06"
+tags: [ "linux", " open source", " programming", " rust", " software", " tools", " imag" ]
+---
+
+This is the first call for participation for the imag project. I have no
+experience writing such calls for participation, so please bear with me!
+
+<hr>
+
+Right now, the imag ecosystem has some tools available which are already
+usable and in rather good shape. There is a contact manager, a diary and a notes
+tool, a habit tracker and a time tracker are there as well, though those are
+not extensively tested by now.
+
+Yet, there is a _lot_ to get done. Here I will list what's missing in the rust
+crate (library) ecosystem as well as what imag modules are missing to get imag
+off the ground.
+
+This is the first roundup of "What to do" - I call this "Call for
+Participation" because I'm effectively asking for help and am looking for
+contributors with this post.
+
+
+# How can I contribute?
+
+There are several ways how one can 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!
+
+
+# imag modules
+
+This first section is about imag tools which are in my personal "pipeline" (in
+my head). I will write them, if not somebody else steps up and starts writing
+them for the imag toolchain!
+
+Some of these todos are long-term todos and need a certain level of
+involvement. Still, I would be more than happy helping and mentoring
+development!
+
+
+## imag-mail
+
+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
+
+Did you ever wanted to implement your own commandline health/workout/diet
+tracker? With the imag project, you get the chance!
+
+
+## imag-todo
+
+(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 importable (and maybe even exportable).
+
+
+## imag-bookmark
+
+`imag-bookmark` is another tool which is rather minimal right now.
+I would like to provide as many useful features as possible and even a
+firefox/chromium plugin, which calls `imag-bookmark` for a new bookmark, would
+be really nice!
+
+
+## imag-entry
+
+A general `imag-entry` command would be nice. It should provide functionality
+to read and write header data and create new entries as well.
+Thus, it may provide the same features as `imag-edit`, as editing would be
+another usecase for a tool `imag-entry`.
+
+
+## TUI
+
+Of course, I want to have a TUI for imag in the future. This TUI includes, but
+is not limited to:
+
+* Dashboard - where a overview of the complete imag store is shown. Of course
+  "overview" is to be defined in that sentence, but I could think of a
+  configurable view into the imag store: Top entries, "new" entries from all
+  modules, a network of entries (imag internal linking creates a network)...
+* Tree of entries / Entry graph - A tree of entries would be nice (which is
+  ultimatively a fancy `ls -R` on the imag store path, but this tree should
+  have several features such as being foldable, show contents and header-data
+  of the entries and so on.
+* Entry view/edit - of course a way for viewing and editing imag entries is a
+  _must_ for a proper TUI.
+
+I do not know, yet, how a tool like `imag-tui` would work internally, as it
+would need to be able to include data (or rather: semantics for the entries)
+from all other modules.
+One way I could think of would be that a generic `libimagtui` provides a way
+to create views for `imag-tui` and all tools from the imag codebase need to
+implement such a view, creating a shared library for it. Then, `imag-tui`
+searches for those shared libraries at startup and loads them into the
+"general" view. This way, `imag-tui` itself would be rather minimal, but load
+functionality dynamically as it is found at startup time.
+
+
+## Library organization
+
+I maintain my personal library with git-annex right now. That means: I collect
+papers and articles in PDF format, but also Novels (fanfiction).
+With a "library organization" tool for imag, I mean a tool which allows me to
+keep notes on papers, organise references, tags and so on, and of course make
+them linkable to the rest of the imag ecosystem.
+
+
+## Project management
+
+This is a bit rough and I did not yet think enough of this to give concrete
+examples. By "project" I mean any type of projects, not only "programming
+projects" or repositories even. Things like Kanban boards come to mind, but as
+these are more "collaborative" tools, and imag is a _personal_ information
+management tool(set), it does not fit well together.
+
+
+# imag ecosystem improvements
+
+Some stuff needs to be improved in the general imag ecosystem (read:
+non-domain libraries).
+
+* Porting the whole ecosystem to use "impl-trait", remove all unneeded
+  iterator types.
+* Porting to failure (WIP).
+* Rewriting/splitting of libimagentrylink into libimagentrylink and
+  libimagentryurl (external linking)
+* Rewrite libimagtimeui to use kairos.
+* Move edit stuff out of libimagutil
+* Rewrite libimaginteraction to not assume stdout.
+* Remove libimagentryref. The whole design is rather suboptimal, especially
+  when using imag on multiple devices where paths are different.
+
+
+# Libraries
+
+Last, but not least: There are certain libraries missing in the rust ecosystem.
+If these libraries would be implemented (hint, hint!), implementing imag tools
+would become even more simple!
+
+
+## Icalendar / vcard
+
+The rust ecosystem does not yet have a standard implementation of icalendar
+and vcard standards. There are - of course - some competing projects tackling
+this, but none of it has a nice and clean high-level interface and features
+both a parser and a writer.
+
+I contributed a few patches to "rust-vobject", which is - in my opinion - the
+best crate for icalendar and vcard right now, but it really needs a lot more
+polishing. Also, its parser is hand-crafted, but really should be implemented
+using some parser framework like "nom", for example.
+
+
+## Email parsing and writing / Maildir access
+
+There's "lettre", which can be used to write emails, but there's no nice
+parser library the last time I searched
+(at least not with a high-level interface - `mailparse` is there and usable of
+course).
+Also, notmuch bindings are missing (more on that later) and libs for reading
+and writing Maildirs are not available yet.
+
+
+## RSS/Atom
+
+There are no libraries for reading and writing RSS and Atom feeds. Those would
+be needed to be able to write a commandline RSS reader (much like
+newsbeuter/newsboat).
+
+
+## Online resource access
+
+What's also missing is helper crates for accessing online resources, such as,
+but not limited to:
+
+* openstreetmap
+* openweathermap
+* project gutenberg (and similar)
+* google scholar
+* scihub
+* wikipedia
+
+
+## Bindings
+
+Also, bindings for a lot of programs are missing.
+
+* notmuch (there's "notmuch-sys", but there's no "safe" and high-level
+  interface for notmuch right now. I
+  [started one](https://github.com/matthiasbeyer/notmuch), but do not have
+  enough time to push it forward)
+* pandoc (there's a crate for calling 'pandoc' on the commandline, but I
+  wonder whether it would be possible to have a _real_ binding)
+* git-annex (bindings for "libgit" exists - a rather good one actually - but
+  not for git-annex)
+
+These are just some bindings I can think of right now.
+
+
+## Cursive
+
+First: Don't get me wrong, `Cursive` is a great crate (although I haven't used
+it yet, but I am following its development rather closely). But for imag, it
+lacks some stuff - some "high level features" - which would make implementing
+a TUI on top of imag rather convenient:
+
+* high-level layout stuff - As far as I know does `Cursive` not yet have a
+  high-level layout framework. What I mean by this is: If I were to
+  reimplement "vim" with Cursive, I don't want to reimplement things like
+  "move buffer to new tab", but simply call a function "here is the view, move
+  that to a new tab named 'foo'". Same goes for splitview, floating windows,
+  moving around floating windows, sidebars and statusbars (`Cursive` has a
+  nice framework for writing a menu bar).
+* modal keybinding processor/framework - There is no keybinding processor
+  which could be used to reimplement modal keybindings like "vim", for
+  example. It would be nice if I could just tell Cursive: If "Ctrl-W" and then
+  "t" are pressed, do the following (move the currently focused buffer to a
+  new window, for example). This is, as far as I know, not possible yet.
+* tree view - there is a crate `cursive_tree_view`, but as far as I remember,
+  it is only possible to view filesystem trees, not custom ones.
+* a view for having a shell inside `Cursive` would be awesome. But I guess
+  `Ctrl-Z` is a solution to this problem, right?
+* graph drawing - it would be really neat if `Cursive` (or an extension crate)
+  would offer a way to draw graphs, like pie charts, bar charts, networks and
+  so on.
+  There is actually a crate which can do this, but as far as I know it is not
+  possible (or rather: it is not easy) to integrate it with `Cursive`.
+