Skip to content
Pablo Villar edited this page Mar 23, 2017 · 43 revisions

🖐 First of all, make sure you've read Inaka's open-source guidelines.

Checklist

The following items must be satisfied for any Swift open source project.

💡 Use this reduced checklist for your github issues.

⚠️ Ask any ops person for admin privileges on your project.

General Items

It has a Github repo The repo address must match this format: https://github.com/inaka/ProjectName
It has a proper [.gitignore](https://github.com/inaka/swift_guidelines/wiki/.gitignore) file Create a `.gitignore` file at the root level (or edit the existent one), and fill it with what's in the link in order to prevent unnecessary files from living in the repo.
It has an [Apache2 LICENSE](https://github.com/inaka/swift_guidelines/wiki/License) file There must be a `LICENSE` file at the root level containing what's in the link. Be aware of the copyright's year: Set it to the current one.
It has a clear and useful [README](https://github.com/inaka/swift_guidelines/wiki/README-Template) file There must be a `README.md` file at the root level whose content must be filled using the template from the link, in order to guarantee a minimum of quality.
Its files and folders are [properly organized](https://github.com/inaka/swift_guidelines/wiki/Project-Organization). A minimal folders' organization is needed for helping cocoapods fetch only the required files. It also avoids conflicts and helps users find relevant information quickly.
It's available in [cocoapods](https://github.com/inaka/swift_guidelines/wiki/Cocoapods) Cocoapods is the most popular dependency manager for Swift projects. In order to reach a considerable audience, the library must have cocoapods support. Besides, users will find the library easier to install. First, make sure your library's name does not already exist in [the index](https://cocoapods.org/). If so, consider renaming it.

Source Code Items

Code is [documented](https://developer.apple.com/library/content/documentation/Xcode/Reference/xcode_markup_formatting_ref/) Each exposed API must have a proper markup documentation following the guidelines from the above link. Why document code? There are lots of articles out there explaining why.
Code is tested Aim for both unit tests and UI tests (if they apply), and remember that [100% coverage is a non-goal](https://jeremybytes.blogspot.com.ar/2016/08/code-coverage-should-not-be-goal.html). Why test code? There are lots of articles out there explaining why.
Code is [linted](https://github.com/inaka/swift_guidelines/wiki/Code-Linting) Why linting our code? **CONVENTION:** Defining and sticking with a style guide helps reduce the amount of decisions that developers need to make when writing code, helping to keep their focus on logic, not semantics and formatting. **CONSISTENCY:** When every line of code is written in the same style, the whole codebase becomes easier to read, understand and de-bug. It also helps prevent areas of the codebase from being “owned” by one person's unique style vs. the team. **PROFESSIONALISM:** A clean codebase is a reflection of a cohesive team. It gives the impression of a team working well together towards a common goal, rather than individual developers working independently.
Every source file uses the [Apache2 License Header](https://github.com/inaka/swift_guidelines/wiki/License-Header) For every `.swift` file in the project, remove the default header, and replace it with the [Apache2 License Header](License-Header).

Continuous Integration Items

It's hooked to HipChat rooms The repo must be hooked to our usual HipChat rooms. Ask those rooms' owners to configure the corresponding webhooks in your repo.
It's hooked to [Travis CI](https://github.com/inaka/swift_guidelines/wiki/Travis-CI-Hook) Travis CI provides continuous integration support for free, for public repos. Having a CI method helps catch builds that fail or whose tests don't pass, and hence, are not ready to production yet.
It's hooked to [Codecov](https://github.com/inaka/swift_guidelines/wiki/Codecov-Hook) Having a code coverage report tool helps maintainers catch parts of the code that aren't covered by tests. Moreover, it gives users a quick report on how much of the code is covered by tests.
It's hooked to Hound TBD

Exhibition Items

There is a [blog post](http://inaka.net/blog/) about it Contact any [blog maintainer](https://github.com/orgs/inaka/teams/blog-maintainers) for further information.
It's shared on social networks Contact any [blog maintainer](https://github.com/orgs/inaka/teams/blog-maintainers) for further information.
It's shared on [Reddit](https://www.reddit.com/) Contact any [blog maintainer](https://github.com/orgs/inaka/teams/blog-maintainers) for further information.
It's shared on [Hacker News](https://news.ycombinator.com/) Contact any [blog maintainer](https://github.com/orgs/inaka/teams/blog-maintainers) for further information.

Current Projects

Our current open-source projects can be seen here.