README clarifications

[hoijui]

I am checking out different in-git issue trackers right now, and browsing yours, I missed (in the README directly):

• the data model (found it later in a linked-to document)
• why you chose not to store issues in files
• if there is a TUI and/or a GUI for submitting issues

I am happy that you still use github issues!
one of the other projects (sit) does not, and it is basically impossible to get in contact with them except though sending emails (adress extracted from git history) to the devs.
... or understanding, compiling, installing, reading docs, creating an issue, submitting .. hopefully all wihtout problems (practically very unlikely).

.. ride on! :-)

[neithernut]

Thanks for your feedback!

• the data model (found it later in a linked-to document)
• why you chose not to store issues in files

These don't really belong into a readme, at least not in my opinion. However, we could make the link to the documentation of concepts and internals a bit more prominent. We could also elaborate a bit more on the design choices.

Sadly, it is unlikely to change in the near future. We have a few things in the pipeline but it gets stalled regularly. Partly because of some decisions we need to make and because of lack of time as well as distractions (Well, let's say I could be a better maintainer). But once we are on track again, I'll make sure to improve the documentation along the way.

if there is a TUI and/or a GUI for submitting issues

There is a web-ui project floating around, but it's anywhere from being really usable. Other than that, there is neither a GUI nor a TUI. At least not that I'm aware of.

[hoijui]

They may not belong into a README, but as I see it, in the case of git-dit, the README is the first thing anyone interested in the project would see, so it is basically also your homepage. Most people landing here will probably look at different distributed issue tracking projects, and they will look for info to compare them, to choose which ones to use/test.
That kind of info has to be available quickly on the project homepage, at first glance.
Ensuring that people coming by who should be interested, are actually interested, should be the highest goal of the public info/homepage. That is the way you get more users (that test) and more devs to help out.
I might be wrong in some things here.. I just wanted to explain my rationale.

[hoijui]

.. thank you for your prompt reply back then! :-)
I see that my reply looks a bit.. aehh robotic.. i was happy got get a reply... thanks!