Code of Conduct

RISC-V is a community organization and it only works if we all respect each other. Our official Code of Conduct is posted on the RISC-V website at https://riscv.org/community/community-code-of-conduct/ , including an escalation process.

But our goals for interaction go beyond the code of conduct.  We must understand that our community is diverse including different cultures, genders, race, etc. We expect people to be thoughtful about everything from word choice, tone of voice, time zones, etc.

Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting RISC-V International at conduct@riscv.org.

We hope that members entering this organization behave constructively. We ask that members don’t get defensive if asked to adjust interactions or behaviors.

We strongly suggest that you don’t let frustrations build over a series of incidents. The earlier we address issues, the easier it will be to be productive in a positive environment.

Please attempt to propose solutions and not just raise issues. This community runs on member participation and good ideas come from you.

Sharing work within the RISC-V community

One of the key reasons for the RISC-V community to exist at all is so that the members do not have to replicate the same or similar work in each company. This helps time to market as well as maintenance and allows resources in member companies to concentrate on innovation.

If you have proprietary value please, by all means, keep it proprietary. But if the technology is a common industry offering or something developed in a RISC-V venue or email, we ask all members to consider contributing their work as early as possible for the benefit of the community the same way that all members benefit from others doing the same.

In the Linux community, the desire is that time to market is not considered proprietary value even if it provides some advantage to members.

Innovation enablement

One major goal of RISC-V is to enable innovation.

To that end all specifications and extensions will be constructed in such a way to enable members to innovate both in the implementation of standard extensions (those defined by RISC-V International) and in member-defined extensions.

Where possible we will require splitting up extensions so that implementers can implement portions of an overall extension (consisting of potentially a number of extensions) swiftly and efficiently.

Balance between for profit and not for profit

We work to enable both for profit and not-for-profit research and products based on RISC-V. There is often overlap with proprietary and open source components. Our intent is to provide robust open source components but still enable for profit companies to innovate and differentiate their products. This is often a fine line and we look to our members to help navigate this topic.

Implementation vs. non-implementation dependent topics

RISC-V International supports and enables the full ecosystem around the RISC-V ISA from industry requirements to design to Applications and everything in between. However we only host extensions, the development of specifications, ecosystem components, and interest groups that are implementation independent.

We work to ensure that whatever is done at RISC-V International also endeavors to enable innovative implementation dependent work.

We fully support and often build alliances with organizations that are non-profit and filling out other parts of the ecosystem.

Fewer things better and more completely

As a philosophy we would, where we can, ask that members concentrate on finishing what we have started rather than have a lot of things in flight that we take a long time to finish.

The number one responsibility of a Task Group (TG) is to define their deliverables, project an end date and finish their deliverables.

We also ask that members look at topics holistically and not only look at single point extensions. 

Please do not confuse groups with meetings. Multiple groups whether they are Committees, SIGs, or TGs may choose to have combined meetings. Often the same members belong to various groups and it is more efficient to combine their meetings.

Accountability and Project Management

All Groups and Specifications are managed out of Jira. Status of these items is continuously available through various sources such as these wiki pages:

• RISC-V Active ICs, HCs, SIGs, and TGs

• RISC-V Specification Status

Additional summaries such as the BoD Report (link) or Jira Kanban boards provide insight into the activities.

We ask each group to periodically update their Jira tasks to reflect their work. In doing so, weask that members do not reverse engineer their answers. In particular don’t say something isn’t needed because you think you know we don’t have the resources to do the work. Instead we ask that you identify what is the right thing to do. The TSC and Chairs will work to identify resources and we allow exception requests.

We do not judge individual groups for being late but we do need to know projections for a number of reasons including: enabling the Chairs, TSC, and BOD to help unblock issues (resource or otherwise) causing the delay, and we need to share our status so the Governance bodies and the community so they know what to expect (one reason is that for example a member may choose to use an unratified specification to create product if a spec won’t be available for a long time in the future).

Sense of urgency - Divide and Conquer

RISC-V international has a sense of urgency to finish specifications and extensions.

As such we ask that TGs break down extensions where it makes sense so a) members can get to market with much needed features that match the ratified extensions and specifications (and not just drafts) and b) so that implementers don’t need to implement all features in a group potentially causing a larger size and/or complexity) or worse yet create a custom extension with a subset.

This may translate into a phased approach of focusing first on developing an extension providing the key functionality that is needed, and deferring other work to separate follow-on extensions that provide expanded or complementary functionality addressing further or more specialized need

Similarly, TGs should strive to avoid feature creep and last minute additions to an extension.  The focus should be on the core functionality that is needed, and functionality that is not essential to this goal should be deferred to follow-on extensions.

Addition of new functionality (including instructions, registers, or CSRs) after an extension has achieved Freeze status is notably undesirable and results in loss of that status.

The board of directors asked to take steps to ensure progress. Divide and conquer is a key piece of it but not all of it. It is important that, for example, we don’t reopen old issues repeatedly. We are not saying never but expect members to use and support good judgment on this.

Majority, Not Consensus

As part of the board of directors asking us to take steps to ensure progress they asked us to make decisions based on majority positive votes and not consensus. This is different from some other open source or standards organizations.

Open Source

RISC-V favors Open-Source Licenses (OSL) that are unencumbered and have no side-effects (i.e. no Copy-Left). Contributions must have this kind of license where applicable. Existing upstream components with other OSL licenses should maintain them as appropriate. Questions as to whether something qualifies, should be directed to help@riscv.org.

RISC-V will maintain 3 logical groupings (Still in discussion):

• Open-source License with no encumbrances or side effects

• Open-source License with encumbrances or side effects

• Closed source

We want to make sure we have a place for people to post what they wish to the community.

We partition it this way so there is no confusion by members.

Members should always inspect what they use regardless of this policy. Please see the GitHub Repo Structure & Administration wiki page for more information.

Timezone friendly

We have members in all timezones. When you plan meetings please be respectful and find a time acceptable to your group members and if necessary switch off between times that are friendly around the world. There is no time that will be easy for every timezone so please be flexible. Also the same times are interesting for all the groups so please coordinate between teams. There is a common calendar here.

Diversity

Diversity and inclusion are important to RISC-V International. Please identify opportunities to increase our diversity wherever you can. This includes outreach to members falling into a diversity group for chair/vice-chair positions, membership, review solicitation, and general communications.

Nomenclature

Most terms have been overused in the industry and even within RISC-V. It is important for us to always define what terms mean before using the, We have a glossary and you may put the definition there and point to it or have nomenclature at the beginning of your meetings or specifications so everyone knows what a term means within context.

Commercial enablement

While we are an Open Source community, our goal is to enable members to create successful businesses that include RISC-V based technology. This may be using RISC-V as the main processor in a system or embedded as a controller on a peripheral or IO cards or DV or Toolchain products, etc.

RVI has a number of goals for working with commercial vendors: 1) educate them around RISC-V and 2) analyze gaps that vendors need that RVI is not currently addressing 3) provide the exchange for publicizing products (see the exchange here).