From 40e99d30e86a8600076d529cc5bcf376bfff323b Mon Sep 17 00:00:00 2001 From: Abhinav Prasai Date: Mon, 6 Oct 2025 21:17:36 +0100 Subject: move CHANGELOG and CONTRIBUTIONS to docs/ --- CONTRIBUTIONS.md | 204 ------------------------------------------------------- 1 file changed, 204 deletions(-) delete mode 100644 CONTRIBUTIONS.md (limited to 'CONTRIBUTIONS.md') diff --git a/CONTRIBUTIONS.md b/CONTRIBUTIONS.md deleted file mode 100644 index 9b4aa1e..0000000 --- a/CONTRIBUTIONS.md +++ /dev/null @@ -1,204 +0,0 @@ -# Contributing to sxwm - -Firstly, thanks for taking the time to contribute to `sxwm`! Your interest -in improving the project is truly appreciated. - -## Code Style and Formatting - -There is an included `clangd` formatting file, but it won’t do everything for you. -Please follow the rules below to keep the codebase consistent and clean. - -### Indentation - -* Use **tabs** for indentation — never spaces. - -### Blocks - -* All blocks of C code must be wrapped in curly braces `{}`. -* Each statement must be on its own line. -* Always add a space between keywords and the opening parenthesis. - -**Example**: - -```c -if (x) { - y(); -} -else { - z(); -} -``` - -### Comments - -* Use this format for comments to maintain consistency: - -```c -/* this is a comment */ -``` - -* For temporary notes, use: - -```c -/* TODO: something to fix */ -/* FIXME: known issue */ -``` - -### Function Declarations - -Functions should look like this: - -```c -void function_x(void) -{ -} - -void function_y(int y) -{ -} -``` - -### Variable and Function Naming - -* Use `snake_case` for all variable and function names. - -**Examples**: - -```c -int some_variable = 2; -float other_variable = 5; - -void do_something(void); -``` - -### Header Guards - -If you create a header file, use header guards: - -```c -#ifndef HEADER_NAME_H -#define HEADER_NAME_H - -// content - -#endif /* HEADER_NAME_H */ -``` - -### Line Length - -* Keep lines under **100 characters** when possible to improve terminal readability. - -### Whitespace - -* No trailing whitespace. -* One blank line between function definitions. -* Avoid unnecessary vertical spacing. - -### Include Order - -Organize includes like this: - -1. Corresponding header (if any) -2. Standard library headers -3. Other project headers - ---- - -## Build - -* `make` must succeed **with no warnings** on your system. -* Don’t commit build artifacts (e.g., `.o`, `sxwm`) or backup files (e.g., `*~`). -* Test your changes, especially on **multi-monitor setups** using **Xephyr**. - ---- - -## File Layout - -* Don’t create new `.c` or `.h` files unless absolutely necessary. -* Keep most changes within `sxwm.c` to maintain cohesion. - ---- - -## Submitting Changes - -* Open a pull request with a **clear description** of what and why. -* Keep **one purpose per commit** — don’t mix unrelated changes. -* If fixing a bug, describe **how to reproduce it**. -* If adding a feature, ensure it fits with `sxwm`’s **minimalist philosophy**. -* **Open separate PRs** for unrelated changes. - ---- - -## Git Commit Guidelines - -* Use imperative mood: `Add foo`, not `Added foo`. -* Keep the summary under 50 characters. -* Add a detailed body if needed. - -**Example**: - -``` -Fix crash when window is closed - -Previously, sxwm would segfault if a client closed itself. -This patch adds a check for null pointers before accessing window data. -``` - ---- - -## Tooling & Analysis - -* Use the provided `.clang-format` file where applicable. -* You may optionally run: - - * `cppcheck` - * `clang-tidy` -* Avoid committing debug code like stray `printf()` or `fprintf(stderr, ...)`. - ---- - -## Editor Configuration - -A sample `.editorconfig` file is provided (or you can request one). -It ensures editors match the project’s formatting conventions. - ---- - -## Documentation - -Update all relevant documentation if applicable: - -* `sxwm.1` -* `README.md` -* `default_sxwmrc` -* `CHANGELOG.md` - ---- - -## Respect the Existing Structure - -* For **large changes**, open an issue for discussion first. -* Do not change code for personal style unless it improves clarity or solves a specific problem. - ---- - -## Testing Checklist - -Please ensure the following before opening a PR: - -* [x] Code builds **without warnings** -* [x] Changes are **fully tested** -* [x] PR includes a **clear explanation** -* [x] Configuration reload works (if relevant) - ---- - -## Code Review Etiquette - -* Be respectful and open to feedback. -* Feel free to ask questions about any review comments. -* Reviews are collaborative and meant to improve the code, not criticize you personally. - ---- - -**Happy hacking!** -- cgit v1.2.3