
# Contributing

Thank you for your interest in contributing to Seekia!

Together, we can facilitate eugenic breeding and help humanity 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 domain name 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 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](https://www.torproject.org/download/)

You should route all traffic on your machine through Tor to shield all network traffic, including when connecting to code repositories via command line tools like `git`.

Performing all of your development activities within a [Whonix](https://whonix.org) 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](https://www.whonix.org/wiki/About)) 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](https://www.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 techniques. Be careful who you trust.

Use signing keys as often as possible when communicating. You can use tools such as [Minisign](https://jedisct1.github.io/minisign/) and Seekia Memos to create signed messages that people can verify were authored by you. Use cryptographically signed and encrypted messaging tools such as [SimpleX Chat](https://simplex.chat/).

## 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.

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:

```Go
//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:

```Go
passed := now - profCTime
```

#### Good:

```Go
timePassed := currentTime - profileCreationTime
```

### 3. Use Parentheses around if statements

#### Bad: 

```Go
if i > 1{
	// Bad
}
```

#### Good:

```Go
if (i > 1){
	// Good
}
```

### 4. Use == true and == false for comparisons

#### Bad:

```Go
if (foo && !bar){
	// Bad
}
```

#### Good:

```Go
if (foo == true && bar == false){
	// Good
}
```

### 5. Break down statements line by line

Break down statements into their component parts, line by line.

#### Bad:

```Go
if (CheckIfSkipped(GetHash(ConvertToInt(identifierString)))){
	// Bad
}
```

#### Good:

```Go
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 practice helps to detect bugs in the code.

#### Bad:

```Go
val := map[i]
```

#### Good:

```Go
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.

```Go
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.

```Go
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.")
	})
```

## Document Attribution

Much of this is document is taken from btcd: [github.com/btcsuite/btcd](https://github.com/btcsuite/btcd)

The data comes from this file: `/btcd/docs/code_contribution_guidelines.md` (ISC License)

