Hello everyone!
I’m excited to introduce you to SprintLang, my first open-source project, an experiment born out of my own need for a more organized approach to project management. I realize it might be a niche solution, but I believe sharing it can lead to valuable feedback and, who knows, it might just be the tool someone out there didn’t know they needed!
SprintLang is a Lightweight Markup Language (LML) specifically designed to simplify the complexities of project management. It provides a structured way to define and manage projects using plain text files, similar to how you’d use markdown.
The design philosophy behind SprintLang is centered on readability and writability, striving to maintain a balance between simplicity for human users and being easily parsed by computer programs. It sould be expressive enough to cater to the diverse needs project management while keeping the user interface as simple as possible.
Why plain text? The beauty of plain text is its simplicity and universal compatibility. It doesn’t require any specific software and can be read and edited on any device. This makes SprintLang a versatile tool for project management that isn’t tied to a specific platform or toolset. I plan to write some tooling around the format, but I don’t want it to be required. It also suits my CLI first workflows.
SprintLang is open-source and licensed under the MIT License, one of the most permissive licenses. This means you’re free to use, modify, and distribute SprintLang however you like, as long as you include the original copyright and license notice. I chose the MIT License to encourage the widest possible use and adaptation of SprintLang.
While SprintLang is currently in its early stages, I believe it has the potential to be a powerful tool for project management. I’m eager to see how it can grow and improve with community input and contributions. If you’re interested in contributing to SprintLang, whether it’s providing feedback, suggesting features, reporting bugs, etc, I would love to hear from you!
Feedback: to see an example one has to click through to another file in the repo.
Is it a subset of Markdown or YAML? It is a type of decision that it would be good to be upfront with to the users. It also gives you a framework for further thinking and development, and some out of the box parsability.
Thanks for the feedback. I think you’re saying that it would be good to see an example not just in the spec files, but right in the readme that GitHub displays when you visit the repo. That’s a good idea. I’ll do that. I’ll also make it more clear that the primary work is in that spec file.
The design was inspired mostly by markdown. I initially mentioned that in the readme but I guess it was lost in my edits. I will add that back. Thanks again.