We love your input! We want to make contributing to NETCore.Keycloak as easy and transparent as possible, whether it's:
- Reporting a bug
- Discussing the current state of the code
- Submitting a fix
- Proposing new features
- Becoming a maintainer
We use GitHub to host code, to track issues and feature requests, as well as accept pull requests.
All branch names must follow this format:
(feature|bugfix|hotfix|docs|refactor)/[a-z0-9_]{5,50}
This means:
- Start with one of these prefixes:
feature/,bugfix/,hotfix/,docs/,refactor/ - Followed by a description that:
- Is 5-50 characters long
- Uses only lowercase letters (a-z), numbers (0-9), and underscores (_)
- No spaces, hyphens, or special characters allowed
Examples:
feature/add_token_refreshbugfix/fix_auth_flow_123hotfix/security_patch_456docs/update_readme_789refactor/simplify_code_101
- Fork the repo and create your branch from
mainfollowing the branch naming convention - Ensure your code follows the existing code style and formatting rules defined in
.editorconfig - Update the documentation if needed
- Ensure all tests pass
- Create a Pull Request with a clear title and description
We use .editorconfig to maintain consistent coding styles. Some key points:
- Use tabs for indentation
- Maximum line length is 120 characters
- UTF-8 encoding
- Trim trailing whitespace
- Insert final newline
- Follow C# naming conventions
- Use proper spacing and bracing rules as defined in
.editorconfig
- All public APIs must be documented using XML documentation comments
- Documentation should follow the standard XML format:
/// <summary> /// Brief description of what the method/class does /// </summary> /// <param name="parameterName">Description of the parameter</param> /// <returns>Description of the return value</returns> /// <exception cref="ExceptionType">When the exception is thrown</exception>
- Include code examples in documentation when the usage is not immediately obvious
- Keep comments up to date with code changes
- Use clear and concise language
- Document non-obvious implementation details or business logic
- Include references to related documentation or external resources when applicable
- Use the present tense ("Add feature" not "Added feature")
- Use the imperative mood ("Move cursor to..." not "Moves cursor to...")
- Limit the first line to 72 characters or less
- Reference issues and pull requests liberally after the first line
- Never commit sensitive information (API keys, credentials, etc.)
- Follow SAST (Static Application Security Testing) rules defined in
.editorconfig - Report security vulnerabilities privately to the maintainers
By contributing, you agree that your contributions will be licensed under the same license as the project.
Don't hesitate to open an issue for any questions or concerns.