Skip to content

Docs: MD updates #584

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
XV02 wants to merge 5 commits into
base: release/v2.4.8.4
Choose a base branch
from
Open

Docs: MD updates #584

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
ad1f578
chore: Update CONTRIBUTING.md
XV02 Mar 19, 2026
5ee79a1
chore: Create proper Code of Conduct
XV02 Mar 19, 2026
84066f2
chore: Update CONTRIBUTING.md
XV02 Mar 19, 2026
2e005ab
chore: Create proper Code of Conduct
XV02 Mar 19, 2026
76b8862
Merge branch 'docs/md-updates' of github-personal:XV02/ltfs into docs…
XV02 Apr 21, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
77 changes: 75 additions & 2 deletions .github/CONTRIBUTING.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -4,7 +4,7 @@ We love pull requests from everyone.

When contributing to this repository, please first discuss the change you wish to make via issue, email, or any other method with the owners of this repository before making a change.

Please note we have a [coding style guide](/docs/CODE_OF_CONDUCT.md), please follow it in all your interactions with the project.
Please note we have a [coding style guide](../docs/coding_style.md), please follow it in all your interactions with the project.

1. Fork, then clone the repo

Expand All @@ -25,5 +25,78 @@ Please note we have a [coding style guide](/docs/CODE_OF_CONDUCT.md), please fol

__Some things that will increase the chance that your pull request is accepted__

* Follow our [coding style guide](/docs/CODE_OF_CONDUCT.md).
* Follow our [coding style guide](../docs/coding_style.md).
* Write a good commit message.

# Branch Naming Conventions
The structure and design conventions are based mainly on the “Conventional Branch” concept and the team’s current work process.

Note: These conventions are recommendations intended to improve readability and consistency of commits within pull requests and are not strictly enforced. Only the release and main branches are required to fully adhere to this naming convention.

## Purpose
1. Purpose-driven Branch Names: Each branch name clearly indicates its purpose, making it easy for all developers to understand what the branch is for.
2. Integration with CI/CD: By using consistent branch names, it can help automated systems (like Continuous Integration/Continuous Deployment pipelines) to trigger specific actions based on the branch type.
3. Better type and version control: Branches are related to a specific type of change in the code and the version that is being worked on, allowing for a much better backtracking.

## Basic Rules
- Naming structure:
`<type>/<description>`
- Naming prefixes (Types):
- feature/: For new features (e.g., feature/add-login-page).
- fix/: For general fixes or code correcting.
- update/: For code upgrade or non-breaking code refactoring.
- chore/: For non-code tasks like dependency, docs updates (e.g., chore/update-dependencies).
- release/: For branches preparing a release (e.g., release/v1.2.0).
- Use Lowercase Alphanumeric and Hyphens: Always use lowercase letters (a-z), numbers (0-9), and hyphens to separate words. Avoid special characters, underscores, or spaces.
- No Consecutive or Trailing Hyphens: Ensure that hyphens are used singly, with no consecutive hyphens (feature/new--login) or at the end (feature/new-login-).
- Keep It Clear and Concise: The branch name should be descriptive yet concise, clearly indicating the purpose of the work.
- Include Ticket Numbers: If applicable, include the ticket number from your project management tool to make tracking easier. For example, for a ticket issue-123, the branch name could be feature/issue-123-new-login.

## General Project Structure
```
main
├── release/v1.x.x
│ ├── feature/lorem-ipsum
│ └── fix/ipsum-dolor
├── release/v2.x.x
│ └── chore/dolor-sit
└── release/v3.x.x
├── update/sit-amet
├── feature/amet-consectetur
└── chore/consectetur-adipiscing
```
- main: This branch should only contain working versions completely tested and only receive pull requests from finalized release branches. All new release/ branches must come from this one.
- release: The creation of these branches should be done from the last version of main when created. Only this branches can make pull requests to main.
- Other branches: All working branches should come from a release branch. These are the only ones that should receive direct commits from changes made by development staff. These branches should only do PR to the active release branch.

# Commits Naming Conventions
The structure and design conventions are based mainly on the “Conventional Branch” concept and the team’s current work process.

## Purpose
1. Automatically generating CHANGELOGs: When the commits are concise, and precise changelogs can be automated or semi-automated from the commit history.
2. Communicating the nature of changes to everyone: Being able to understand the type of changing by just looking at a name and understanding the basics of a commit just by the title is useful in analysis and backtrack situations.
3. Building code habits and good practices: Maintaining structured commits also leads to more precise coding practices and coherent code changes.

## Basic Rules
- Naming structure:
```
<type>: <description>

[optional body]
```
- Naming prefixes (Types):
- fix: A commit of the type fix patches a bug in your codebase.
- feat: A commit of the type feat introduces a new feature to the codebase
- <type>!: A commit that appends a ! after the type introduces a breaking change. A breaking change can be part of commits of any type.
- update: A commit of type update changes existing code or refactors functions without changing functionality of adding features in your codebase.
- build: A commit of type build changes build process in your codebase.
- docs: A commit of type docs is for creation or updating documentation in your codebase.
- chore: A commit of type chore is for every other minor task in your codebase.
- Commits must be prefixed with a type, which consists of a noun, feat, fix, etc., followed by the optional !, and required terminal colon and space.
- A description must immediately follow the colon and space after the type prefix. The description is a short summary of the code changes, e.g., fix: array parsing issue when multiple spaces were contained in string.
- A longer commit body may be provided after the short description, providing additional contextual information about the code changes. The body must begin one blank line after the description.
- A commit body is free-form and may consist of any number of newline separated paragraphs.

# Bibliography
[1] “Conventional Branch,” Conventional Branch, 2025. https://conventional-branch.github.io/ (accessed 2025).</br>
[2] “Conventional Commits,” Conventional Commits. https://www.conventionalcommits.org/en/v1.0.0/ (accessed 2025).
201 changes: 79 additions & 122 deletions docs/CODE_OF_CONDUCT.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,133 +1,90 @@
Coding Style guide for LTFS
=============
# Code of Conduct

Naming conventions
-------------
## Our Pledge

- We don't use capital letters, except on defines and enumerators (see below).
- Public APIs are always prefixed by the name of that module:
* ltfs.c: ltfs_statfs(), ltfs_open(), ltfs_close(), ltfs_read()
* fs.c: fs_resolve_dentry(), fs_set_name(), fs_set_creation_time()
We pledge to make our community welcoming, safe, and equitable for all.

We are committed to fostering an environment that respects and promotes the dignity, rights, and contributions of all individuals, regardless of characteristics including race, ethnicity, caste, color, age, physical characteristics, neurodiversity, disability, sex or gender, gender identity or expression, sexual orientation, language, philosophy or religion, national or social origin, socio-economic position, level of education, or other status. The same privileges of participation are extended to everyone who participates in good faith and in accordance with this Covenant.

Spaces, tabs and commas
-------------
## Encouraged Behaviors

When indenting the code, always use TABs with 4 spaces. Do not replace TABs by spaces. Remove trailing spaces of a line and empty lines at the end of file.
While acknowledging differences in social norms, we all strive to meet our community's expectations for positive behavior. We also understand that our words and actions may be interpreted differently than we intend based on culture, background, or native language.

When writing arguments to a function or defining enums, also use the following comma conventions:
With these considerations in mind, we agree to behave mindfully toward each other and act in ways that center our shared values, including:

1. Respecting the **purpose of our community**, our activities, and our ways of gathering.
2. Engaging **kindly and honestly** with others.
3. Respecting **different viewpoints** and experiences.
4. **Taking responsibility** for our actions and contributions.
5. Gracefully giving and accepting **constructive feedback**.
6. Committing to **repairing harm** when it occurs.
7. Behaving in other ways that promote and sustain the **well-being of our community**.

```
call_function(arg1, arg2, arg3);

call_another_function(
very_long_argument1,
very_long_argument2,
very_long_argument3
);

enum very_cool_enumerator {
VERY_COOL_1,
VERY_COOL_2,
VERY_COOL_3,
};
```

Macros and defines
-------------

When defining wrappers around functions using macros do that using lowercase characters. Defines always go in uppercase.

```
#define wrapper_around_some_function(x,y) \
...

#define LTFS_MAX_VALUE 2112
```

Functions
-------------

Return type, function name and its parameters should go all in a single line, except if the parameters are too long.


```
void ltfs_function(void *params)
{
}

void ltfs_function_with_many_parameters(void *params1,
void *params2, void *params3)
{
}
```

Conditional tests
-------------

```
if (condition) {
line 1;
line 2;
} else
line 3;

if (another condition)
do this;
else
do that;

if (yet another condition) {
/*
* It's ok to open brackets when adding comments,
* just to make it clear where the scope ends.
* That can improve readability when comments
* span across multiple lines.
*/
do something else;
}
```

Loops
-------------

```
for (x=start; x<end; ++x) {
body
}
```

Comments
-------------
## Restricted Behaviors

Please do not use C++ style comments (//), except when
temporarily commenting out a line of code. If too many
lines are being commented out consider using #if 0 instead
or, preferably, just remove that code completely.

For comments, always use the C style (/* comments */),
even if that's just a single line.
We agree to restrict the following behaviors in our community. Instances, threats, and promotion of these behaviors are violations of this Code of Conduct.

1. **Harassment.** Violating explicitly expressed boundaries or engaging in unnecessary personal attention after any clear request to stop.
2. **Character attacks.** Making insulting, demeaning, or pejorative comments directed at a community member or group of people.
3. **Stereotyping or discrimination.** Characterizing anyone’s personality or behavior on the basis of immutable identities or traits.
4. **Sexualization.** Behaving in a way that would generally be considered inappropriately intimate in the context or purpose of the community.
5. **Violating confidentiality**. Sharing or acting on someone's personal or private information without their permission.
6. **Endangerment.** Causing, encouraging, or threatening violence or other harm toward any person or group.
7. Behaving in other ways that **threaten the well-being** of our community.

### Other Restrictions

1. **Misleading identity.** Impersonating someone else for any reason, or pretending to be someone else to evade enforcement actions.
2. **Failing to credit sources.** Not properly crediting the sources of content you contribute.
3. **Promotional materials**. Sharing marketing or other commercial content in a way that is outside the norms of the community.
4. **Irresponsible communication.** Failing to responsibly present content which includes, links or describes any other restricted behaviors.


## Reporting an Issue

Tensions can occur between community members even when they are trying their best to collaborate. Not every conflict represents a code of conduct violation, and this Code of Conduct reinforces encouraged behaviors and norms that can help avoid conflicts and minimize harm.

When an incident does occur, it is important to report it promptly. To report a possible violation, **communicate with @jjashgar or @chukero**

Community Moderators take reports of violations seriously and will make every effort to respond in a timely manner. They will investigate all reports of code of conduct violations, reviewing messages, logs, and recordings, or interviewing witnesses and other participants. Community Moderators will keep investigation and enforcement actions as transparent as possible while prioritizing safety and confidentiality. In order to honor these values, enforcement actions are carried out in private with the involved parties, but communicating to the whole community may be part of a mutually agreed upon resolution.


## Addressing and Repairing Harm


If an investigation by the Community Moderators finds that this Code of Conduct has been violated, the following enforcement ladder may be used to determine how best to repair harm, based on the incident's impact on the individuals involved and the community as a whole. Depending on the severity of a violation, lower rungs on the ladder may be skipped.

1) Warning
1) Event: A violation involving a single incident or series of incidents.
2) Consequence: A private, written warning from the Community Moderators.
3) Repair: Examples of repair include a private written apology, acknowledgement of responsibility, and seeking clarification on expectations.
2) Temporarily Limited Activities
1) Event: A repeated incidence of a violation that previously resulted in a warning, or the first incidence of a more serious violation.
2) Consequence: A private, written warning with a time-limited cooldown period designed to underscore the seriousness of the situation and give the community members involved time to process the incident. The cooldown period may be limited to particular communication channels or interactions with particular community members.
3) Repair: Examples of repair may include making an apology, using the cooldown period to reflect on actions and impact, and being thoughtful about re-entering community spaces after the period is over.
3) Temporary Suspension
1) Event: A pattern of repeated violation which the Community Moderators have tried to address with warnings, or a single serious violation.
2) Consequence: A private written warning with conditions for return from suspension. In general, temporary suspensions give the person being suspended time to reflect upon their behavior and possible corrective actions.
3) Repair: Examples of repair include respecting the spirit of the suspension, meeting the specified conditions for return, and being thoughtful about how to reintegrate with the community when the suspension is lifted.
4) Permanent Ban
1) Event: A pattern of repeated code of conduct violations that other steps on the ladder have failed to resolve, or a violation so serious that the Community Moderators determine there is no way to keep the community safe with this person as a member.
2) Consequence: Access to all community spaces, tools, and communication channels is removed. In general, permanent bans should be rarely used, should have strong reasoning behind them, and should only be resorted to if working through other remedies has failed to change the behavior.
3) Repair: There is no possible repair in cases of this severity.

This enforcement ladder is intended as a guideline. It does not limit the ability of Community Managers to use their discretion and judgment, in keeping with the best interests of our community.


## Scope

This Code of Conduct applies within all community spaces, and also applies when an individual is officially representing the community in public or other spaces. Examples of representing our community include using an official email address, posting via an official social media account, or acting as an appointed representative at an online or offline event.


## Attribution

This Code of Conduct is adapted from the Contributor Covenant, version 3.0, permanently available at [https://www.contributor-covenant.org/version/3/0/](https://www.contributor-covenant.org/version/3/0/).

Contributor Covenant is stewarded by the Organization for Ethical Source and licensed under CC BY-SA 4.0. To view a copy of this license, visit [https://creativecommons.org/licenses/by-sa/4.0/](https://creativecommons.org/licenses/by-sa/4.0/)

For answers to common questions about Contributor Covenant, see the FAQ at [https://www.contributor-covenant.org/faq](https://www.contributor-covenant.org/faq). Translations are provided at [https://www.contributor-covenant.org/translations](https://www.contributor-covenant.org/translations). Additional enforcement and community guideline resources can be found at [https://www.contributor-covenant.org/resources](https://www.contributor-covenant.org/resources). The enforcement ladder was inspired by the work of [Mozilla’s code of conduct team](https://github.com/mozilla/inclusion).

For documenting functions, please use the Doxygen-friendly
format below:

```
/**
* General comments about the function go here.
* @param var1 Describe what var1 does.
* @param var2 Describe what var2 does.
* @return Describe what's expected to be returned both on
* success and on error situation. Also, note that we
* tabulate with one extra space when the comments span
* multiple lines.
*/
int function(void *var1, void *var2)
{
}
```

Maximum line length
-------------

Lines must not exceed 100 characters.
Loading
Loading