My first CloudFest Hackathon in 2023 was also the first time I led a project there. It was also the first time CloudFest Hackathon had a female project lead. I loved the project and the experience, despite the hassle of getting there. The team was great (we won the Dream Team award!), collaboration with people you just met, coding over the weekend and staring at the “unsolvable” problem all night, finding a solution in the last minute, pushing code and merging every 2 minutes, planting an Easter egg… It was marvellous!!
And then we went home. The project died.
The experience was so unique and valuable, though, that I was coming back in the following two years as a participant. But didn’t want to lead the project. Don’t need another dead one, with domain renewal reminders of yet another unfulfilled idea. I couldn’t think of anything important for the entirety of open-source, anyway.
But this year I had a big problem to solve. As a documentation contributor at WordPress.org, I’ve been doing so much tedious manual work around the documentation that I have very little time to do the actual documenting. I got sick of it. The engineer part of me wants to automate everything that doesn’t need thinking, everything that’s just a blueprint, the structure, everything I have to do more than once, everything that’s boring… All I wanted was to write the docs. So I needed a tool that would do all the boring parts for me.
We started with Block2Docs proposal. I didn’t like the name, but the name was less important at that moment. It was important to start, to build something that can do at least something.
The team was small. Almost too small. And there was a problem in aligning with the scope, structure, and goal of the project. Small misunderstandings at the beginning rippled into major disalignment by the end of day two.
I was preparing the “we didn’t finish the project” presentation in my mind. But also, the curious mind is always seeking a solution. And I was lucky that my team had curious minds. One of them, JJ, prototyped the solution. At least one part of it. We didn’t have time to test it in different scenarios or on different laptops, but hey, it works on her machine 🤷♀️. It was good enough to serve the goal and set the principle.
As we were trying out new things and adding them, I was modifying the presentation in my mind. We kept reordering slides. Adding and removing, modifying and reordering – that pretty much sums up the last morning of the hackathon. And we finally landed on the project name. It was a rather quick and loud change, indubitably.
Doc2Me!!
Say it out loud, I dare you. And the use cases…
Doc2My hand ✋
Are you Docing2Me? 🤨
Don’t you love it? I love it!
Is the project what you planned, Milana?
Yes, and no. The project parses the code, uses specific @tags from code comments, reads the config file and git diff, and builds different stuff for you:
- code reference for PHP and JS
- Changelog
- GitHub issues
It uses SKILLS for AI agents to perform some of these tasks. I never planned to use AI. I know it sounds silly in today’s environment. But I wanted a tool that is completely open-source and free. If this tool is relying on AI, it will be limited at best. So I will make sure that everything can be done without the AI as well.
On the other hand, using AI to build the structure of documentation does feel good. It’s faster and more reliable than other uses of AI today. But other than AI usage, I didn’t really plan anything. And it’s a good thing when preparing a project for the hackathon. To make it a real hackathon project, all you need is a good problem and a definition of WHAT needs to happen to solve it. You don’t need the HOW. The HOW is the fun, hacky part. Don’t rob your team of it.
The most important thing is: this project is solving my problem.
The most important thing is: this project is solving my problem. Not completely. Not yet. Just enough so that I can continue working on it to get it there. That means that this project won’t die. It can not. I need it alive and working.
I’ve got the feeling that not many people understood the impact this project can have. But how can they? None of them had to deal with all the documentation issues it’s going to solve. At first, I wanted to build a tool that would enable everyone to have complete documentation for their software projects. After working on it for these 3 days, and discussing all the specifications, I realised that only documentarians will be able to understand, appreciate, and use this tool to its extent. And I can live with that.
The future
The future for this tool is crazy in my mind. I plan to cover every type of software documentation with it. Still don’t know the details, but I know one important premise. This tool will NOT write the documentation for you. It will analyse your code, use changes from the code to build various documents, it will build the structure, the tasks, the lists… You will never miss a piece of documentation your software need. But you will have to write most of it yourself.
This tool will not use AI to write the documentation. AI needs good documentation, and this tool will enable you to have it.
The project
The team
(from left to right):
- Wendie Huis in ‘t Veld
- Milana Cap
- Mary J (JJ) Jay
- Remkus de Vries
- Johannes Bremer
Project’s links:
- Project GitHub ORG: https://github.com/Doc2Me
- Parser repo: https://github.com/Doc2Me/Parser
- Website (coming soon): https://doc-2.me/
- Pitch slide
- Presentation slides