Work on an Issue

The Flutter Bounty Hunters welcome code contributions from developers who are excited about, and invested in Static Shock.

Before working on an issue, please be sure to ask the team to assign it to you. We wouldn't want multiple people to spend their time solving the same problem.

You should also provide some information about your familiarity with the task, and what you plan to do to implement it. We wouldn't want you to go down a long path that ends up failing at the end.

Follow Patterns

When fixing a bug, or implementing a feature, try to match your code style to the existing Static Shock code. We will enforce consistency wherever possible, so we recommend focusing on consistency from the very beginning. Otherwise, it might be frustrating to finish implementing the ticket, and then have to rewrite most of the code to honor existing styles and patterns.

Tests

Tests are critical. Static Shock includes a lot of overlapping behaviors. It's easy to change a behavior in place only to have it break a behavior somewhere else.

You should expect to write tests for every bug fix and every feature.

To help you, we've published an entire section on testing.

Documentation

What you're reading right now is documentation. The only reason these words exist is because a human sat down and wrote them. Every capability within Static Shock is worthy of documentation. Every contributor should expect to write some amount of documentation.

Documentation takes three forms:

• Website guides
• DartDoc comments (in code)
• Inline comments (in code)

Contributors are expected to write all three types of documentation, where valuable.