Hey everyone, thanks for the great discussion over in #telodendria-general:bancino.net
. This newsletter is a formal acknowledgment of that discussion, and an announcement of some of the changes I'm going to implement as a result.
As always, I apologize for the lack of development that's been going on around here. I'm going to try to keep things moving as best I can, and I think some of the changes coming down the pipeline are going to make it easier for me to get help so this isn't just a one-man show.
First off, I just want to say that I appreciate all the suggestions I got the other day. Clearly there is a lot of room for improvement on my part, and I want you all to know that I am committed to making Telodendria the best it can be. The project goals themselves (written in C, minimal dependencies) are still solid and unchanged, but it has become apparent to me that the way we go about achieving those goals needs to change a bit to actually be successful. It has come to my attention that the development process in specific is extremely unfriendly. This needs to change if Telodendria is going to have a strong community around it. Additionally, I realize that Telodendria's target audience is ill-defined. This also needs to change if we hope to "market" Telodendria to the masses. I know we can't appeal to everyone, but by clearly defining and targeting a specific audience, we will get quality contributors that share our interests. Finally, I want to place a stronger emphasis on convention, and less on strict standards compliance. Up to this point, Telodendria has striven for strictly POSIX compliance, which has caused some noticeable divergence from the typical conventions of projects of this nature. We need to fix this so that new contributors are not burdened by having to learn an unfamiliar, custom build system, for example.
It was also mentioned that I haven't been very transparent in my personal development of Telodendria. While I strive to write newsletters detailing all of my thoughts, this is not enough. My release roadmap is poorly defined, my development checklist is sloppy, and I have no real, hard timelines for anything. You all rightfully expect better from me as the lead of what I hope will grow to into a healthy, sustainable project. I want to be more professional and do things correctly; it was always my goal to build an open-source product that is useful to others, and not just some small casual side project, so I apologize for conducting operations as casually as I have been.
I value the community's input, and I've really contemplated it because I don't want this to be a one-person project; I do want a strong community that can help move the project forward when I inevitably run out of time to put in long hours writing code. Even though some of the changes requested go against my initial personal convictions and ideas for how I initially wanted this project to be developed, I want to be flexible and realize that project needs change, and what worked for me, a single developer, isn't going to work for the entire community. With that being said, I am genuinely excited to announce some changes that I hope will move Telodendria forward by making it easier for contributors to get involved, easier for end-users to read documentation, and easier for the common person to understand what Telodendria is all about and why we, the community, feel that it's important.
There are a number of large project management level changes that I have implemented, am in the process of implementing, and am intending to implement:
#telodendria-patches:bancino.net
, will be shut down as soon as I get around to it. It won't be needed anymore, because pull requests will suffice.#telodendria-issues:bancino.net
, will also be shut down. It won't be needed anymore, because Gitea issues will suffice.#telodendria-releases:bancino.net
, will be shut down too. It won't be needed anymore, because Git releases will suffice, and I am fairly certain that Gitea provides an RSS feed for that if notifications are desired. I can also just post release announcements to the main room.man
page documentation will be going away. Documentation will become markdown files that are rendered in Gitea instead. The user documentation should be distinct from the developer documentation.README
, which will target our developers.https://telodendria.io/pub
. Tarballs will just be made available as Git tags. I won't delete the current /pub
directory, but I'm not going to deploy tarballs there anymore.Among the changes will also be the deletion of the #telodendria-ports:bancino.net, because there are no active users in that room. We can just use the main room for discussing ports if necessary. #telodendria-newsletter:bancino.net will stay for the time being, but I may try to figure out how to move newsletters to the main website for better visibility.
With the management changes, there are also going to be some substantial repository structure changes:
TODO.txt
file will be deleted. Gitea issues will be created for everything that's currently in there, and I'll be sure to set up the projects and milestones in Gitea to accurately reflect the information currently in TODO.txt
.man
will need to be converted to Markdown and placed in a new /docs
directory in the repo. We'll have /docs/user
and /docs/dev
for user and developer documentation respectively. I am opting not to use the Gitea Wiki feature, because using plain Markdown files that live in the repo allows us to ship the documentation with each release automatically, allowing it to be used offline. Additionally, mirrors of the code (such as the GitHub mirror) will automatically mirror the documentation too.Make
. If we can only maintain two Makefiles
(one for Cytoplasm, and one for Telodendria), that would be ideal, but if we have to ship a GNUmakefile
as well, we can do that as necessary. The current system of shell scripts works great, but it's not conventional. Using Make
will make Telodendria much more familiar for people that develop in C, and everyone in general seems to be more comfortable with a project that uses the standard tooling available to it instead of building something custom.Here's what I'm committing myself to:
This whole process is going to take some time, so please be patient as things progress. My first order of business from here is going to be to migrate everything out of TODO.txt
and into Gitea issues/projects/milestones. From there, I'll start converting documentation to markdown and adjusting it as necessary. You all are more than welcome to pitch in and help out in this process as well. Now that we're using Git, you all can use the standard pull request procedure that you're familiar with. And don't hesitate at all to start opening issues on the repository! That is a valid and much needed form of contribution too.
And, as always, if you want to financially support the project—time and computers aren't free after all—you can find the links here and on the main website:
That's it from me for now, but share your comments with me! In particular, let me know if I missed anything important.