Project organization
====================

Licensing
-------------

`reuse.software <https://reuse.software/>`_: to make your project "REUSE-compliant", meaning a set of tools and guidelines to license correctly your project using existing standards.

Versionning
----------------

`semver.org <https://semver.org/>`_: a standard way to semantic versionning in the MAJOR.MINOR.PATCH style.

Changelog
---------------

`keepachangelog.com <https://keepachangelog.com/>`_ is a method to document your changelog (a file which contains a curated, chronologically ordered list of notable changes for each version of a project) by a standardized file.

Documenting
-------------------

`Write the Docs <https://www.writethedocs.org>`_ is a community (With conference, meetups...) gathering "people who care about documentation", bringing `guides to write good documention <https://www.writethedocs.org/guide/>`_.

A podcast named `"the not boring techwriter" <https://www.thenotboringtechwriter.com/>`_ does exist on the subject.

ARCHITECTURE file
--------------------------

If your project is in the range of 10k-200k lines of code, create an ARCHITECTURE.md (or dot whatever you want) : it may helps occasionnal (or not so occasionnal) contributors to enter quicker in your project, saving them time and energy to determine were to do the code changes and how write a patch. It should help to create the mental map of the project you have in mind when your a seasonned contributor.

This file should describe shortly the high-level architecture of the project, a cing of code map plus sections on cross-cutting concerns, specifying things that are unlikely to frequently change (`source <https://matklad.github.io/2021/02/06/ARCHITECTURE.md.html>`_).

A good example is `rust-analyzer's architecture.md <https://github.com/rust-lang/rust-analyzer/blob/d7c99931d05e3723d878bea5dc26766791fa4e69/docs/dev/architecture.md>`_.