Something as artistically and conceptually broad as a whole language can easily be construed to be multi-faceted. As a self-taught software architect by trade, I tend to see the entire Chraki project mostly through the lens of (a) developer(s) coding a pile of data to eventually be used by end-users. Whereas, as an artist, I see the aesthetic features of its symbols and grammatical choices as if I was painting a picture or writing a book.
Recording Your Progress
The point of either of these example viewpoints is that Chraki right now stands out as a developing project, to be written by its contributors. I have learned through various hardships, that when one develops a product, be it a computer game, book, or painting, it’s an exceptionally good idea to be able to record its progress. Having access to your notes, reasons for decisions, or just being able to see how an idea has changed or been modified over time can be invaluable for both analysis and morale.
This is why, when searching or deciding on wiki software for the site, I opted for a system that enables administrators to (at least) look back on the last twenty versions of an article. Storing every version back to the beginning would be ideal, but those are the limits of my current software. I also looked for some way to be able to share groups of files, be they SVG files for symbols, or computer code for parsing/displaying Chraki, in such a way that their development and changes over time could be recorded. Both of these functionalities enable stable and secure community collaboration without, in my opinion, getting in lost in needless bureaucracy.
Version Control And Its Systems
- Centralized Vs. Decentralized
- Why I Didn’t Use GitHub
What I’ve described here is what is generally known as a version control system. These kinds of systems have been present in software development, where the precise content of files is king, for quite a while. In fact, Wikipedia.org defines version control (or revision/source control) as:
… the management of changes to documents, computer programs, large web sites, and other collections of information. Changes are usually identified by a number or letter code, termed the “revision number”, “revision level”, or simply “revision”.
The idea is that as you make incremental changes to a project and its source files, these changes get tagged and organized in such a way that, if need be, you can revert back to them at any time. It’s like an interactive backup manager for your computer, so one could think of Apple’s Time Machine as an example.
I believe version control can be helpful for the Chraki project not just as a measure and recording of programming, but of all pertinent materials concerning the project including fonts, SVG files, and other information. In this vein, I have looked over various version control systems to see what they have to offer.
Centralized Vs. Decentralized
There are two flavors of version control at the moment, with one more recent than the other. Older systems such as CVS, Subversion and Perforce work around the idea of a central server that stores all of the relevant information. While this seems appealing, considering that there’s only one “Official” Chraki, it has its drawbacks. Working with external parties in the project introduces a number of potential issues when such parties must rely upon or work with only one central server.
To mitigate some of these issues there are distributed version control systems, which do not necessarily rely on one single canonical server to store the project information. These are newer developments and include software such as Git, or Mercurial. Git in recent years has really made an impact in terms of adoption and publicity, partially thanks to such repository websites such as GitHub which have community and integration tools to go alongside the core Git services.
Why I Didn’t Use GitHub
Git is fairly easy to understand, and to work with (in my opinion) even on the command line, plus it’s been widely adopted, so it was an easy choice for our purposes. I have naively used the GitHub code repository service for quite some time. I say naively because I’m not generally a “repository geek,” meaning that for the most part, I’m more interested in coding than getting deep into the nuts and bolts of Continuous Integration and Delivery and other topics. For the most part, particularly when GitHub began to allow private repositories even for community (free) members, it has worked fairly well.
GitHub And The United States Government
However, it came to my attention that the company that runs GitHub has a standing contract with the United States government agency known as USCIS and/or ICE. I do not know about that contract in grave detail, admittedly, but I do know that in having that contract they are in one way or another supporting (and profiting from) the operations of these governmental agenc(ies). Given the state of the current administration, that is unacceptable to me.
Needless to say, my immigration policies do not match the Trump administration’s (nor the last three administrations and more). The treatment I believe people deserve as (illegal) immigrants/asylum seekers is a far cry from what they receive today. It’s a sad reality, but in this climate, I must also stress that I am not in favor of dangerous individuals being let into our country either.
What’s My Stake In This?
I do not speak about this academically, as I have been privy to and gone through the difficulties and hardships imposed by the immigration system for the last fifteen years ever since I became involved with my significant other who is a foreign national. Having this experience, particularly when we were the victims of discrimination within this system for thirteen years, has fostered a strong conviction in me.
What I Decided To Use
It is for this reason, as well as the desire to not be reliant on a free (or paid) service, that I have opted to not use GitHub for my version control hosting. Instead, I am relying on a server provided by Novelty Factor LLC (a company sponsor of this project of which I am also an investing member) that runs the GitLab Enterprise software.
This software enables this project to take advantage of the features and (open-source) power of GitLab, its integrations, and its friendly community-oriented interface. All future publicly available (software) files for all Chraki projects rest on this server at https://kadarlab.noveltyfactor.com/the-official-chraki-repository.
Currently, there exists one repository, which you can download, clone, fork, and share using HTTPS and Git endpoints, and that is the syllabary. This project is the culmination of much of my earlier work (pre chraki.dev) on the language project. It contains all the pseudo-syllables in SVG and Adobe Illustrator format both separately, and as one giant SVG file couple with CSS (which allows you to embed an SVG file in HTML and using selectors determine what shows up.)
Contributions and Community
This doesn’t just allow me to disseminate this data on a friendly unbiased basis, it also opens the door for future contributions. I have written previously about the content licenses of contributions, and those ideas hold here as well.
At the moment you need an account on the GitLab installation if you hope to actually do pull requests, merge, or otherwise affect the main repository itself. This means that some of the issues of a centralized server still remain, but I believe that this set-up minimizes the impact. In order to cooperate and work with other contributors on the repository itself, contact me so I can enable an account for you.
You don’t need an account to peruse the files, download a copy of them, and I don’t believe you need one to clone the repository. For most users, that should be enough. I hope that with the addition of this repository to the project, we can move forward with development on a stable footing.
With that out of the way, go check out the syllabary repository if you want to get your hands on what I’ve used or formatted for the project so far. I’m currently working on some Chraki processing tools, in particular a possible Regular Expression for parsing pseudo-syllables, and how it might compare to a hand-made parser in terms of efficiency and portability.