This month in FlavaQuest: Documentation.

Now that I’ve made solid progress on the core functionality of FlavaQuest, I decided it was time to take a step back and start documenting the project. And let me tell you, it was a struggle.

Why Document at All?

I’ve written documentation before, but only for smaller side projects for work. FlavaQuest is different. It’s bigger, more complex, and something I genuinely want to share with others. Whether that’s future collaborators, open-source contributors, or just curious developers, I want the documentation to make the vision of FlavaQuest crystal clear.

So I dove in headfirst. My first hurdle? Where should this documentation live?

Choosing the Right Tool

I wanted something that was:

• Easy to access
• Simple to use
• Version-controlled
• Collaborator-friendly

After some back and forth and a quick consultation with ChatGPT, I landed on using GitHub Wiki. It was the perfect balance. Everything lives with the repo, you get version control, and it's super easy to navigate. Win-win.

The Blank Page Problem

Now that I had the tool, I was faced with the real challenge: what do I write?

There’s no universal template for documentation, and I couldn’t find a standard approach that fit my app. Most guides were either too vague or tailored to large enterprise-level projects.

So I did what any good dev does when they hit a wall: I asked ChatGPT. This time, the results weren’t that helpful. It was too generic or too technical for my needs. I needed something focused on frontend documentation and mobile apps.

Then I came across this fantastic Medium article that broke things down in a really clear way. It outlined how to approach frontend documentation: breaking things into components, pages, logic, structure, and user flow. That article gave me the clarity and structure I needed.

Writing the Docs

Even with the guide in hand, writing documentation wasn’t easy. I try to adhere to Clean Code Principals. However, it felt like I didn’t need to document much. But I reminded myself: Documentation isn’t just for explaining the code—it’s for explaining the system.

To help speed things up, I asked ChatGPT to help generate some initial drafts of the docs based on my code files. It actually worked surprisingly well. I cleaned up what it wrote, filled in the gaps, and ended up with something I’m proud of. Now I have a solid documentation template I can use moving forward.

GitHub Wiki Surprises

After pushing my first few pages to the GitHub Wiki, I hit a snag: folder-based routing doesn’t work like it does in a normal code repo. I had structured the wiki pages into folders, but GitHub Wiki treated them as flat files.

Here’s the fix I ended up using:

# Wrong way
[folder/file.md](folder/file.md)

# Correct way
[folder/file.md](file)

Instead of using folders, I just referenced the file names. The only problem with this is that every file has to be unique.

Another surprise? GitHub Wiki commits don’t count toward your contribution graph.

So if you’re someone who tracks those green squares, just know: documentation work in the Wiki won’t show up.

What’s Next?

With documentation finally in place, I feel more confident about bringing others into the project. It also helped me clarify some ideas I had floating around in my head. Writing things down made the project feel real.

Feel free to check out the FlavaQuest Wiki and let me know what you think!