The Swift.org community has the singular goal of making the world’s best general purpose programming language. Collectively we will develop the language in the open, with contributions from anyone who wishes to participate. This guideline document describes how the Swift community is organized so that we can work together to add amazing new capabilities to Swift, and make it available to even more developers across more platforms.
The Swift language is developed in the open, and all technical or administrative topics about the language or community processes should be directed to the Swift public forums. Public conversations are encouraged, and active developers of the Swift language should monitor the relevant forum categories.
- Directory of forum categories and email instructions are in the forum section
- Source code for all Swift projects can be found on GitHub at github.com/apple
- The Swift.org bug tracking system is maintained at bugs.swift.org
Advancing the Swift programming language with a coherent, clear view of its evolution requires strong leadership. The leadership is taken from the community, and works closely with the much broader group of contributors and users. Roles within the community include:
- Project lead appoints technical leaders from the community. Apple Inc. is the project lead, and interacts with the community through its representative.
- Core team is the small group of engineers responsible for strategic direction
- Code owner is the individual responsible for a specific area of the Swift codebase
- Committer is anyone that has commit access to the Swift code base
- Contributor is anyone that contributes a patch or helps with code review
There is also a code of conduct working group to help in matters of community, culture, and the code of conduct. Most importantly, everyone that uses Swift is a valued member of our extended community.
Apple Inc. is the project lead and serves as the arbiter for the project. The project lead makes senior appointments to leadership roles, with those leaders coming from the worldwide Swift community of contributors. The community leaders and code contributors work together to continually improve Swift, and the language will advance by the good works of everyone involved.
Ted Kremenek (email@example.com) is the appointed representative from Apple, and acts as the voice of the project lead.
The Core Team reviews and helps iterate on language evolution proposals from the community at large, acting as the approver of these proposals. Team members help drive Swift forward in a coherent direction consistent with the goal of creating the best possible general purpose programming language.
Members of the core team are appointed by the project lead based on their technical expertise and proven contribution to the community. The current core team members are:
- Ben Cohen (firstname.lastname@example.org)
- Chris Lattner (email@example.com)
- Dave Abrahams (firstname.lastname@example.org)
- Doug Gregor (email@example.com)
- Joe Groff (firstname.lastname@example.org)
- John McCall (email@example.com)
- Ted Kremenek (firstname.lastname@example.org)
At project launch, the team is composed of Apple employees due to Swift’s origin within Apple. Over time, exceptional community members from a much more diverse background will be appointed based on their record of community involvement and contributions.
Code owners are individuals assigned to specific areas of the Swift project, with code quality their primary responsibility. The umbrella Swift project is composed of numerous sub-projects including the Swift standard library, extensions to the LLDB debugger, and the Swift package manager, to name a few. Each sub-project will be assigned a code owner. The code owner then works to get all contributions reviewed, gather feedback from the community, and shepherd approved patches into the product.
Anyone can review a piece of code, and we welcome code review from everyone that is interested. Code review procedures are not dictated by a central, global policy. Instead, the process is defined by each code owner.
Any community member that is active and shows themselves to be valuable can offer to become a code owner via posting to the forums, or be nominated by another member. If fellow contributors agree, the project lead will make the appointment and add the new owner’s name to the code owners file. The position is completely voluntary, and can be resigned at any time.
The list of current code owners can be found in the file
CODE_OWNERS.txt in the root of the parent Swift source tree. We also maintain a mailing group so you can send an email to all the code owners.
There may be nothing more important to the success of Swift than strong, engaged code owners. We all owe them respect, gratitude, and whatever help we can offer.
The Swift license is based on the Apache 2.0 license with a Runtime Library Exception that removes the attribution requirement when using Swift to build and distribute your own binaries. The Apache 2.0 license was chosen because it allows broad use of Swift, and is already well-understood by many potential contributors.
Copyright is held by the authors of the contributions, or the company or organization to which the individual belongs. A list of copyright holders is maintained in the CONTRIBUTORS.txt file on Swift.org and at the root of the repository.
Runtime Library Exception
The Runtime Library Exception makes it clear that end users of the Swift compiler don’t have to attribute their use of Swift in their finished binary application, game, or service. End-users of the Swift language should feel unrestricted to create great software. The full text of this exception follows:
As an exception, if you use this Software to compile your source code and portions of this Software are embedded into the binary product as a result, you may redistribute such product without providing attribution as would otherwise be required by Sections 4(a), 4(b) and 4(d) of the License.
This exception can also be found at the bottom of the LICENSE.txt file.
Copyright and License in Source Code
All source files hosted on Swift.org must contain a comment block at the top of the file declaring the license and copyright that applies. This text may be part of a larger header, for instance as defined in the Contributing Code section. Regardless of the header format, the wording for the license and copyright portion must be copied as follows, with the appropriate years applied:
// This source file is part of the Swift.org open source project // // Copyright (c) 2014 - 2018 Apple Inc. and the Swift project authors // Licensed under Apache License v2.0 with Runtime Library Exception // // See http://swift.org/LICENSE.txt for license information // See http://swift.org/CONTRIBUTORS.txt for the list of Swift project authors
Each contributor is responsible for adding his or her name to the
CONTRIBUTORS.txt file at the project’s root and maintaining the contact information. If you are contributing under the umbrella of your company, please add your company’s information, and do not also list yourself as an additional copyright holder.
The Swift.org site welcomes everyone interested in the Swift programming language. Members of the community can greatly help the Swift project by filing and screening bugs, aiding in code review, participating in open conversations, and of course by contributing code.
It is highly recommended that you become familiar with using Swift in your own projects before contributing directly to the language itself. We put together handy Getting Started guides with step-by-step instructions to get you up and running.
Swift.org exists primarily to welcome contributions from the community. In the simplest cases, one-off patches are welcome from everyone. However, regular contributors are expected to adopt processes that help create a culture of quality within the project.
We ask that contributors first read through the content in the Contributing section of this site. This content includes detailed instructions on the process to follow when contributing a patch, including creating a pull request to get your code into the main Swift code base.
Bugs for the various Swift projects are managed in a public bug tracking system at bugs.swift.org. Anyone can file bugs, or view them to find where they can help, or to see if a bug they found is already filed.
Proposing New Features
New features or directions for the Swift language can come from anyone with a good idea. Open discussion and iteration over the ideas in a public forum is essential to reaching the best possible solutions. Each Swift version should be clearly defined, resulting in “One True Swift” that is source compatible for that release across all supported platforms.
To support this process, Swift.org details the Swift Evolution Process, with links to the high level goals for the current release. Patches that aid in these goals will be given priority, and are more likely to get the immediate attention of code review.
Code of Conduct
To be a truly great community, Swift.org needs to welcome developers from all walks of life, with different backgrounds, and with a wide range of experience. A diverse and friendly community will have more great ideas, more unique perspectives, and produce more great code. We will work diligently to make the Swift community welcoming to everyone.
To give clarity of what is expected of our members, Swift.org has adopted the code of conduct defined by contributor-covenant.org. This document is used across many open source communities, and we think it articulates our values well. The full text is copied below:
Contributor Code of Conduct v1.3
As contributors and maintainers of this project, and in the interest of fostering an open and welcoming community, we pledge to respect all people who contribute through reporting issues, posting feature requests, updating documentation, submitting pull requests or patches, and other activities.
We are committed to making participation in this project a harassment-free experience for everyone, regardless of level of experience, gender, gender identity and expression, sexual orientation, disability, personal appearance, body size, race, ethnicity, age, religion, or nationality.
Examples of unacceptable behavior by participants include:
- The use of sexualized language or imagery
- Personal attacks
- Trolling or insulting/derogatory comments
- Public or private harassment
- Publishing other’s private information, such as physical or electronic addresses, without explicit permission
- Other unethical or unprofessional conduct
Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful.
By adopting this Code of Conduct, project maintainers commit themselves to fairly and consistently applying these principles to every aspect of managing this project. Project maintainers who do not follow or enforce the Code of Conduct may be permanently removed from the project team.
This code of conduct applies both within project spaces and in public spaces when an individual is representing the project or its community.
Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting a project maintainer at email@example.com. All complaints will be reviewed and investigated and will result in a response that is deemed necessary and appropriate to the circumstances. Maintainers are obligated to maintain confidentiality with regard to the reporter of an incident.
This policy is adapted from the Contributor Code of Conduct version 1.3.0.
A working group of community members is committed to promptly addressing any reported issues. Working group members are volunteers appointed by the project lead, with a preference for individuals with varied backgrounds and perspectives. Membership is expected to change regularly, and may grow or shrink.
Note: We will update this section with the names of our working group members in the coming days.
We ask that you report concerns by sending an email to the working group rather than to any individual member. If you would like to volunteer to participate in the working group, please contact the working group.
The primary method of communicating among community members is through the Swift forum. Within the forum, we have a number of categories and sub-categories, to help organize discussions. Forum topics can be further organized via use of tags.
In addition to the forum web interface, the forums can be interacted with via email. Subscriptions and email preferences are configured via forum user settings.
The three main categories in the forum are Evolution, Development, and Using Swift. General announcements for the Swift project and CI notifications are also posted here.
Using Swift - For newcomers or those primarily interested in using the Swift language, it is best to start by engaging within the Using Swift category. This area is intended for users to get help with or ask questions about Swift or its related tools and is not for discussion about work being done to the language itself. This category will accept email sent to: firstname.lastname@example.org
Compiler - For developers to discuss the development and implementation of the Swift compiler, low-level runtime, and SourceKit. This category will accept email sent to: email@example.com
Standard Library - For developers to discuss the implementation of the Swift standard library. This category will accept email sent to: firstname.lastname@example.org
Core Libraries - For developers to discuss the implementation of the Swift core libraries. This category will accept email sent to: email@example.com
Server - For developers to discuss the implementation of new server focused capabilities developed by the Server APIs work group. This category will accept email sent to: firstname.lastname@example.org
LLDB - For developers to discuss the implementation of the Swift REPL and Swift-specific aspects of LLDB. This category will accept email sent to: email@example.com
Package Manager - For developers to discuss the implementation of the Swift package manager. This category will accept email sent to: firstname.lastname@example.org
LLBuild - For developers to discuss the implementation of the low level build system (llbuild). This category will accept email sent to: email@example.com
Announcements - For announcements relevant to developers such as release announcments, branching, and infrastructure updates.
CI Notifications -Automated notifications from ci.swift.org for build and test failures.
Please see the Swift evolution repository to learn about Swift’s evolution process and which proposals are actively being discussed.
Announcements - For announcements of Swift evolution proposal reviews and results. All discussion and review of evolution proposals occurs on the swift-evolution mailing list.
Pitches - For proposals for the evolution of Swift including new language features, new standard library APIs, and so on before they enter the review phase. This category will accept email sent to: firstname.lastname@example.org
Proposal Reviews - Posting and commentary on proposals in the review phase. This category will accept email sent to: email@example.com
Discussion - For general discussion of the evolution of Swift. This category will accept email sent to: firstname.lastname@example.org