forked from NationTech/harmony
		
	
		
			
				
	
	
		
			37 lines
		
	
	
		
			1.1 KiB
		
	
	
	
		
			Markdown
		
	
	
	
	
	
			
		
		
	
	
			37 lines
		
	
	
		
			1.1 KiB
		
	
	
	
		
			Markdown
		
	
	
	
	
	
| # Contributing to the Harmony project
 | |
| 
 | |
| ## Write small P-R
 | |
| 
 | |
| Aim for the smallest piece of work that is mergeable.
 | |
| 
 | |
| Mergeable means that :
 | |
| 
 | |
| - it does not break the build
 | |
| - it moves the codebase one step forward
 | |
| 
 | |
| P-Rs can be many things, they do not have to be complete features.
 | |
| 
 | |
| ### What a P-R **should** be
 | |
| 
 | |
| - Introduce a new trait : This will be the place to discuss the new trait addition, its design and implementation
 | |
| - A new implementation of a trait : a new concrete implementation of the LoadBalancer trait
 | |
| - A new CI check : something that improves quality, robustness, ci performance
 | |
| - Documentation improvements
 | |
| - Refactoring
 | |
| - Bugfix
 | |
| 
 | |
| ### What a P-R **should not** be
 | |
| 
 | |
| - Large. Anything over 200 lines (excluding generated lines) should have a very good reason to be this large.
 | |
| - A mix of refactoring, bug fixes and new features.
 | |
| - Introducing multiple new features or ideas at once.
 | |
| - Multiple new implementations of a trait/functionnality at once
 | |
| 
 | |
| The general idea is to keep P-Rs small and single purpose.
 | |
| 
 | |
| ## Commit message formatting
 | |
| 
 | |
| We follow conventional commits guidelines.
 | |
| 
 | |
| https://www.conventionalcommits.org/en/v1.0.0/
 |