tgyTry this new approach to project management write all tasks needed to be done inside git repository readme. Possibly use separate md or txt file, only in case your readme is already huge (3 targeted documentations, screenshots, contributors guide). In later case use roadmap.md/roadmap.txt.
Why?
I feel like processes around development take too much time off of developers. And ticketing solutions are simple to get rid of, as they just store description of updates to be made. Just by writing projects requirements in the main file of your project, you will get the ability to quickly look this information up. Whether you are leader thinking on backlog, developer choosing tasks, or other team member looking to contribute, readme always hits you in the face once you start searching for information.
How?
If you are not familiar with git features, you may be confused on how to apply this advanced technique. First, when tasks are created, they are created in bulk and during task insertion into codebase the same review process as in code review can be used. This omits need for planning meetings, as all planning is done asynchronously and all feedback is heard and incorporated into plan (unlike on meetings). Format of tasks could be declared in any way, but for convenience I would define it like so “FIXME#3 login button is too big” or “TODO#005 database architecture”, so that later on you could perform search for all tasks easily. This would also highlight tasks in text editor and allow referencing specific code in a task.
Then, after the task is done, in the same change, author removes this task from the readme. Git stores all history, so it can be easily consulted if needed. After task is done, no more additional steps are required.
Limitations
What I don’t know is whether you can perform text search across all files across all of the git repository history. From the point of laws of physics this is permitted, but it may pose long waiting times.