9.8 KiB
Contributing
Thank you for your interest in contributing to Seekia!
Together, we can facilitate eugenic breeding and help people mate in a genetics aware manner.
Ways To Help
1. Spread the Seekia philosophy.
Ideas are unstoppable. Awaken the world to the value of genetics aware mate discovery technology.
2. Buy Domains
If you support the goals of Seekia, buy Seekia domains on ICANN and blockchain DNS providers.
This will prevent bad actors from using these domains for nefarious purposes.
3. Contribute to the codebase.
There are many TODOs throughout the code that describe things that need to be fixed and built.
Auditing the codebase and sharing insights is valued.
See /documentation/Future Plans.md for ideas on things to build.
Code contribution guidelines
Warning!
Due to the controversy associated with eugenics, genetics, and the problems that Seekia attempts to solve, it is recommended to contribute anonymously.
You should access the code repository, any Seekia websites, and perform all of your Seekia related research through the Tor anonymity network.
It is recommended to begin doing this right now, even if you don't currently plan on ever contributing to the codebase.
Use the Tor browser to access websites anonymously. Download the Tor Browser Bundle at torproject.org/download
You should route all traffic on your machine through Tor to shield all network traffic, including connecting to a code repository via command line tools like git.
Performing all of your development activities within a Whonix virtual machine is an easy way to route all of your traffic through Tor, and to protect yourself against other fingerprinting deanonymization attacks.
The Whonix Wiki (whonix.org/wiki) is a good resource to learn about Whonix, and how to protect your online anonymity.
You should deeply consider this advice, and spend some time thinking about your decision to be anonymous or not. The risks facing contributors to Seekia are unpredictable and potentially significant, especially in the early stages of the world becoming aware of Seekia.
Seekia's legal status will take time to be decided, and could even be criminalized in some countries. For example, Tinder was banned in Pakistan.
Learn about the limitations of VPNs here: whonix.org/wiki/Whonix_versus_VPN
If you have decided to not be anonymous, you are an asset. Having some non-anonymous contributors is useful because they can generally be trusted more than anonymous people. Non-anonymous contributors can be more trusted to be administrators, run trusted servers and operate other Seekia-related infrastructure.
Beware Of Advanced Adversaries
Beware that advanced adversaries may attempt to introduce vulnerabilities into the code, cause social conflicts, or compromise Seekia in other ways. They may use social engineering and other sophisticated methods. Be careful who you trust, and use signing keys as often as possible when communicating. You can use Seekia Memos to create signed messages that people can verify were authored by you.
Development Practices
Developers are expected to work in their own trees and submit pull requests when they feel their feature or bug fix is ready for integration into the master branch.
No contribution is too trivial. Even a one character typo fix is welcome. We want the code to be perfect.
Share Early, Share Often
We firmly believe in the share early, share often approach. The basic premise of the approach is to announce your plans before you start work, and once you have started working, craft your changes into a stream of small and easily reviewable commits.
This approach has several benefits:
- Announcing your plans to work on a feature before you begin work avoids duplicate work
- It permits discussions which can help you achieve your goals in a way that is consistent with the existing architecture
- It minimizes the chances of you spending time and energy on a change that might not fit with the consensus of the community or existing architecture and potentially be rejected as a result
- The quicker your changes are merged to master, the less time you will need to spend rebasing and otherwise trying to keep up with the main code base
Testing
One of the design goals of Seekia is to aim for complete test coverage.
Unless a new feature you submit is completely trivial, it should be accompanied by adequate test coverage for both positive and negative conditions.
That is to say, the tests must ensure your code works correctly when it is fed correct data as well as incorrect data.
Go provides an excellent test framework that makes writing test code and checking coverage statistics straight forward.
Before submitting your pull request, test your changes with the go test ./... command.
This command will run all existing tests to ensure that your changes have not broken anything.
All code should be accompanied by tests that ensure the code behaves correctly when given expected values and that it handles errors gracefully.
When you fix a bug, it should be accompanied by tests which exercise the bug to both prove it has been resolved and to prevent future regressions.
Seekia still has many packages which need tests to be written.
Comments
Comments are encouraged.
Functions should be commented with their outputs described like so:
//Outputs:
// -bool: My identity hash exists for provided profileType
// -[16]byte: My identity hash
// -error
func GetMyIdentityHash(myProfileType string) (bool, [16]byte, error){
Code Approval Process
All code which is submitted will need to be reviewed before inclusion into the master branch.
The code must be approved by the project maintainer(s) to be included.
After the code is reviewed, the change will be accepted immediately if no issues are found.
If there are any concerns or questions, you will be provided with feedback along with the next steps needed to get your contribution merged with master.
Either the code reviewer(s) or interested committers may help you rework the code, or you will simply be given feedback for you to make the necessary changes.
This process will continue until the code is finally accepted.
Acceptance
Once your code is accepted, it will be integrated with the master branch. Typically it will be rebased and fast-forward merged to master as we prefer to keep a clean commit history over a tangled weave of merge commits. However, regardless of the specific merge method used, the code will be integrated with the master branch and the pull request will be closed.
Rejoice as you will now be listed as a contributor!
Licensing of Contributions
All contributions must be released into the public domain. See Unlicence.md
The exception is for code that is taken from elsewhere, in which case, you must provide the license for the copied code.
Code Style
Below describes the coding style that contributors should use.
Simplicity and readability are more important than speed and brevity.
The exception is for code that would be noticeable to the end user if it were made faster.
Below are some style guidelines:
1. Use Camel Case
Use camel case for variables and function names.
thisIsAnExampleOfCamelCase
2. Avoid abbreviations and acronyms.
Use descriptive variable names. This may make lines and variable names seem excessively long, but I prefer it that way. When variable names are getting too long, it can be a sign that a simplification of the code is possible.
Bad:
passed := now - profCTime
Good:
timePassed := currentTime - profileCreationTime
3. Use Parentheses around if statements
Bad:
if i > 1{
// Bad
}
Good:
if (i > 1){
// Good
}
4. Use == true and == false for comparisons
Bad:
if (foo && !bar){
// Bad
}
Good:
if (foo == true && bar == false){
// Good
}
5. Break down statements line by line
Break down statements into their component parts, line by line.
Bad:
if (CheckIfSkipped(GetHash(ConvertToInt(identifierString)))){
// Bad
}
Good:
identifierInt := ConvertToInt(identifierString)
hash := GetHash(identifierInt)
isSkipped := CheckIfSkipped(hash)
if (isSkipped == true){
// Good
}
6. Always Use value, exists := mapObject[key]
We must always get exists, even if we have no reason to believe the value does not exist.
This is because cosmic rays and faulty hardware can cause bits to flip, so we should at least try to catch these kinds of errors.
This practice also helps to detect bugs in the code.
Bad:
val := map[i]
Good:
val, exists := map[i]
7. Indenting Style
If you are checking if err != nil and returning err, you don't need to indent.
If you are returning errors.New("Something"), you must indent.
if (err != nil){ return err }
if (name != "Seekia"){
result := errors.New("Invalid name: " + name)
return result
}
If you are defining a function, use standard indenting.
If you are defining a nested function, you must indent the lines containing the function.
newFunction := func(){
log.Println("Seekia: A genetics aware mate discovery network.")
}
newButton := widget.NewButton("Select Me", func(){
log.Println("Seekia: A genetics aware mate discovery network.")
})
8. Return variables, not results
Store the result from a function into a variable before returning it.
Bad:
func badFunction(){
return foo()
}
Good:
func goodFunction(){
result := foo()
return result
}
Document Attribution
Much of this is document is taken from btcd: github.com/btcsuite/btcd
The data comes from this file: /btcd/docs/code_contribution_guidelines.md (ISC License)