-
Notifications
You must be signed in to change notification settings - Fork 189
Principles for Open Development
As the maintainers of CUDA Core Compute Libraries (CCCL), we are committed to open development. We believe that to build a thriving ecosystem around CCCL, it's vital to promote broad adoption and active contribution from developers everywhere.
We strive to cultivate an environment where anyone can participate, learn, and contribute. By making our contributors stakeholders, we not only assure them of a project they can rely on but we also gain valuable insights into their needs and priorities.
Our commitment extends beyond simply making our source code available. We are dedicated to open development of CCCL, carrying out project operations transparently and inclusively. This includes holding all discussions that impact the design of the library in the open. We prefer to host these discussions on GitHub issues or discussion boards, avoiding internal-only mediums like Slack or email whenever possible.
We recognize that some aspects of CCCL may require closed development, especially those related to unreleased hardware or features. Although these components may initially be developed in a closed manner, our intention is always to release them in the open once the hardware or features are publicly released.
While we acknowledge these necessary exceptions, we are dedicated to maintaining the open nature of our project. We strive to minimize closed development, designing our processes to favor open development, even if this makes closed development more challenging.
References: Contributor Guide
Whenever there is both open and closed development within CCCL, we always prioritize open development systems and processes as the source of truth.
This includes maintaining the public main branch as the most upstream branch at all times.
All other branches integrate the latest changes from main regularly.
Closed development must adapt to changes and decisions made in the open. We place the responsibility of managing conflicts between open and closed components on the developers of the closed components. If closed branches are maintained in a separate version control system, we strongly urge the preservation of the history of open branches to simplify future integrations.
We are committed to conducting CCCL's project planning and development processes in the open.
This includes using a GitHub Project board as our source of truth for all day-to-day task tracking and roadmap. We invite everyone to stay up-to-date with our progress by referring to the Project board.
In order to be transparent about how we do what we do, we publish all of our planning and development processes on our GitHub Wiki.
Even when coordination between open and closed components is necessary, we promise to maintain transparency. Planning for closed development, while occurring privately, must consider and adapt to the public planning.
References: GitHub Project Usage, Triage Process, Release Planning, Sprint Planning
We assure that reviews and approvals for changes to CCCL will occur in the open via GitHub Pull Requests and reviews.
References: Code Review Process.
We commit to tracking all CCCL issues in the open whenever possible, even if they affect only closed parts of the project. We encourage developers of closed components to demonstrate and explain issues openly, transforming closed use cases into open ones as appropriate. Any closed issue tracking system is secondary to our open issue tracking that serves as the source of truth.
References: Issue Maintenance, Issue Types.
We are committed to using open continuous integration during the review and approval of changes to CCCL. Closed continuous integration systems may be used to provide additional verification, but any problems arising in them must be demonstrated in the open.
References: CI Overview
By adhering to these principles, we hope to foster a more inclusive, robust, and successful project. We greatly appreciate your understanding and invite you to join us in this endeavor.
This document is adapted from @brycelelbach 's "Principles for Open Projects".