Project organization

Licensing

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: a standard way to semantic versionning in the MAJOR.MINOR.PATCH style.

Changelog

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 is a community (With conference, meetups…) gathering “people who care about documentation”, bringing guides to write good documention.

A podcast named “the not boring techwriter” 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).

A good example is rust-analyzer’s architecture.md.