This blog post is part of a series of posts detailing the development process of AlloyCI. The previous entries have been:
Now that we have started a new project, we most certainly have a lot on our minds about what needs to be done. We might already know where to start, what comes next, and how to get there, or we might not.
If we already know what we want, it makes perfect sense to write it down, give it form, and expand on the ideas and use cases we want to tackle.
If we don’t, then writing down the goals we want to accomplish will most likely light the way. Once we have written the main goal, the next step would be to break it down into smaller goals, and the those goals into smaller tasks that we can accomplish easily.
In both cases, we need a way to keep track of what we need to work on. For a software project, GitHub issues are a great tool for this.
You can create an issue for every task that needs to be tackled, keep them, organized using labels, e.g. have a label for User related, or front-end related tasks, and to keep a record of your progress.
I have been using them for AlloyCI since early on. The project has different labels to organize different issues, and filter them. Even though, for now, it’s only me working on AlloyCI, having all the tasks that need tackling, and also a history of what has already been done, will really help anyone wanting to get started with the project.
It might seem tedious if it’s only you working on a project to devote so much time to issues, but it will really help. You will most likely be the one that benefits the most once you come back after a few months of not working on the project and see the list of thing to be done. If you hadn’t written them down, you would have most likely forgotten about this tiny feature you wanted to add, that seems unimportant but greatly increases user’s happiness.
If you want to go a step further and keep track of what issues are being worked on, what their statuses are, and what the next steps are, you can use GitHub’s Issue Boards. The Boards allow you to create columns that represent stages of the development process, like “In Progress”, “Waiting Review”, “To Be Deployed”, etc. They give you an instant visual overview of how the project is progressing.
To keep myself motivated I also added milestones to the issues. The first milestone was v0.1, in other words, the minimum amount of functionality needed in order for AlloyCI to actually be a CI coordinator. I set a date for it, as a tentative goal for when I wanted to be done with the first part. I wasn’t able to keep it (I pushed it back at least 2 times and by more than 2 months), but it gave me something to aim for.
For v1.0 I haven’t set a date, it is an open milestone, because there are some pretty complex issues assigned to it, but I still look at it as a goal. That is where I want the to project to be. It can be in a few months, in can be next year, but I know I’m going to get there.
There are many tools to help you with project management, but for a small team (or a team of one) the tools GitHub gives you for free are more than enough to get you where you need to be.
In this article, we’re going to explore why young programming languages with modern features can’t be adopted quickly. Additionally, we’re going to take a look at one exceptional example that got specific parameters right to be both young, modern and mature, just ready for adoption at small and big scale.