This article is the translation of french version thanks to DeepL
I just read this article and I can’t stop thinking about it. I’m putting it into perspective for GitRoot contributors. I’m the only contributor (apart from my friend Damien, who corrected numerous typos, thank you to him) on this project. And as this toot shows, I have a job to pay the bills, a wife and two children who take up practically all the rest of my time. On top of that, I have GitRoot. For now, I’m having a blast and hanging in there, but how long can I keep it up?
So why not have external contributors on GitRoot?
I often tell myself that the project is young, too young, to be accessible to an external developer. Sometimes I think that a better issues system would be necessary to have a “welcome new contribution” label. Sometimes I think that once I’ve deployed the SDK plugins and created a plugin marketplace, then you can come and help me make GitRoot a true open-source project.
But, because there is a but, this list will never end. Let’s be honest, there will always be something else to do before you can help me make GitRoot the best it can be. So I decided to do the simplest thing possible right now to explain how you can help me: a blog post.
Here, I’ll explain everything that can be done in the current state of the project. Not what might be possible someday, but what you can do right now. I’ll repeat this kind of article as often as necessary.
There isn’t much you need to do to get ready to help out on GitRoot:
If you want to code, you will also need:
And now you’re ready to start helping. But what should you do? Well, like any good developer, I’ll answer, “It depends.”. It depends on what you want to do! I’ll list a set of possible tasks below, and you can choose.
Before telling you what you can do, I thought it would be a good idea to explain what I am doing. So, for this version 0.3.0, my top priority is to make sure that GitRoot builds GitRoot itself. Currently, for each release, I build the binaries on my machine and then scp them. I want this to no longer be the case with version 0.3.0.
So, if I can restrain myself, I shouldn’t have to do the following tickets. You have all the time you need to do them. The easiest thing, I think, is to meet up on matrix channel gitroot to discuss them.
We can also talk about it by email contact@gitroot.dev or on the fediverse [forge@gitrrot.dev](https://gts.gitroot.dev/@forge).
English is not my native language, and I think there are a lot of typos, so one task could be to read all the MD files in /doc/, /blog/, and maybe even /issues/. Correct them, create a branch, and push. I’ll take care of the rest!
It would be great to create (or find) a theme. GitRoot currently uses simplecss, and it only needs classless CSS. There are many available, but you can also create one for GitRoot.
The easiest way to try it out is to run the make testsuite command. When it’s finished, go to cd /tmp/repo1, edit the style.css file, then git add . git commit -m "try style" and git push. Open http://127.0.0.1:4546/repo1.
When you are satisfied, create a branch with your CSS in apex, then git add . and git push. I’ll take care of the rest.
Okay, no worries, here’s a list of small tasks (well, they seem small to me, but if that’s not the case for you, let me know):
<item>.String to &str doesn’t mean much to me, but if you are, I’m sure it’s a small task. The code can be found in the plugin sdk and the hop plugin.Perfect, there’s plenty to do:
runtest.sh, along with others.
quiet_git(), report(), or mySleep() to other files (and importing them) would be a great help to the project. You can also create new ones for killGitroot(), which is done at the beginning of each file. Or createProject(), which consists of going to the root repository each time and adding its name to the .gitroot/repositories.yml fileYou are welcome to join the gitroot channel on Matrix. Or contact us by email at contact [AT] gitroot.dev or on the Fediverse at @forge@gitroot.dev on this server.