This action will force synchronization from MindSpore/community, which will overwrite any changes that you have made since you forked the repository, and can not be recovered!!!
Synchronous operation will process in the background and will refresh the page when finishing processing. Please be patient.
MindSpore is embracing open governance to build a truly open source ecosystem and developer friendly atmosphere. The governance model adopted here is heavily influenced by the onnx governance which drew reference from the kubernetes governance. For similar structures some of the same wordings from onnx governance are borrowed to adhere to the originally construed meaning.
MindSpore open governance adopts three types of governance structures: Technical Steering Committee, Special Interest Groups (SIGs) and Working Groups (WG). MindSpore also defines two roles for development: Contributor and Approver. Contributors are the developers who have contributed code which got merged and Approvers are those who have the right to merge code. Contributors can vote and run for the Approver role. The Technical Steering Committee charters SIGs/WGs and appoints SIG/WG chairs. Every piece of MindSpore belongs to some SIG. Contributors and Approvers participate in one or more SIGs.
The effort is bootstrapped with an initial Technical Steering Committee and set of SIGs with the first elections to occur after 1 year.
The MindSpore community adheres to the following principles:
Contributors are the developers who have contributed code and got merged. They can have issues and PRs assigned to them. They also have voting privileges. Contributors can be active in many ways including but not limited to:
The first group of Contributors will be appointed and more Contributors will be added accordingly.
Approvers are Contributors who have the right to merge code. Approvers are responsible for reviewing contributions for acceptance by considering not just code quality but also holistic impact of the contribution including compatibility, performance, and interactions with other areas.
Approvers need to be active Contributors for at least 3 months and will be selected in a voting process within a SIG/WG by all the related Contributors. The first group of Approvers will be appointed for an one-year term. After the first year all the Approvers need to be qualified through open elections.
Community Partners are organizations (include but not limited to companies, universities, research institutes, industrial associations, open source foundations/communities/projects, etc.) that support MindSpore in one or more of the following ways:
Community Partners do not have any voting rights, except via their employees who are Contributors. Affiliates and subsidiaries are considered as separate organizations. Being a Community Partner does not by itself confer any compliance or certification to the Community Partner's products.
Community manager is the people who help run day to day MindSpore governance operations. The role is appointed by the Technical Steering Committee and does not have any code or voting related privileges by its own right. The role does not have a term limit and its duration depends only upon the governance charter approved by the Technical Steering Committee.
The MindSpore community is organized in the following manner, with all governance and execution being planned and coordinated as follows:
The working language in MindSpore community is English, this applies to things like code notation, documentation, ISSUE, PR and so forth. International language support for documentation translation and localized presentations are highly encouraged. An i18n WG could be formed to address multi-lang support.
The Technical Steering Committee has a set of rights and responsibilities including the following:
The Technical Steering Committee (TSC) consists of representatives from the community. The first group of TSC members will consist of representatives from the founding members. The chairperson of the TSC will be appointed for the first term. No single member entity may have more than 1 representative. TSC chair and members all serve 1 year terms.
TSC Chair is the chairperson of the Technical Steering Committee that fulfills the duties include hosting TSC meetings, organizing elections and participating promotion related publicities. TSC Chair is a member of the sitting TSC and has the same voting right as any other TSC member.
After the initial term, TSC members will elect the new TSC Chair for the next term. The TSC member seat itself will constitute representative from the same founding member entity, unless alterations occurs to that membership which leads to either new TSC member appointed by the newly TSC-approved member entity, or the vacancy of the seat if the TSC votes to shrink the size of the committee.
Additionally, TSC might create new Contributor representative seats which could be open for any Contributor in the community to be elected into the seat via a community vote. Only Contributors may vote, but would be restricted to no more than one representative elected per member entity.
If a representative of the Technical Steering Committee changes affiliations, by default the original member entity should appoint a new TSC representative. If the employment change results in a single member entity having more than one representative, then one of them must resign. If the founding member entity fails to appoint a new TSC representative, the TSC will decide the new seat. Elections will be held for the seat which is elected.
A Technical Steering Committee representative can be removed due to Code of Conduct violations by a super majority vote in the TSC.
The Technical Steering Committee (TSC) requires quorum of the member to be present for any type of decision making process. An official TSC decision will be carried through by a majority vote (i.e more than half of the TSC vote yes).
During the first year of the TSC term, in order to ensure the smooth progress of the community, if TSC meeting does not get quorum in live attendance, then an email quorum voting procedure will be initiated. If email voting does not get quorum in a week, then the motion will be treated as approved if there is no outstanding objection from any of the TSC member.
The MindSpore project is organized primarily into Special Interest Groups, or SIGs. Each SIG is comprised of individuals from multiple companies and organizations, with a common purpose of advancing the project with respect to a specific topic.
Our goal is to enable a distributed decision structure and code ownership, as well as providing focused forums for getting work done, making decisions, and on-boarding new Contributors. Every identifiable part of the project (e.g., repository, subdirectory, API, test, issue, PR, IRC) is intended to be owned by some SIG. At the time of inception of this organizational structure, the following SIGs will be present:
|FrontEnd||This SIG is responsible for the development of MindSpore front-end expression.|
|Compiler||This SIG is responsible for the development of MindSpore high level graph compilation.|
|Executor||This SIG is responsible for the development of MindSpore back-end support for pipeline.|
|ModelZoo||This SIG is responsible for the development of MindSpore modelzoo and additional ops.|
|Data||This SIG is responsible for the development of MindSpore data processing and data format transformation.|
|GraphEngine||This SIG is responsible for the development of MindSpore graph engine for Ascend AI processor.|
|Visualization||This SIG is responsible for the development of MindSpore visualization tools.|
|Security||This SIG is responsible for the development of MindSpore security related tools.|
|AKG||This SIG is responsible for the development of MindSpore auto kernel generator.|
SIGs must have at least one, and may have up to two SIG chairs at any given time. SIG chairs are intended to be organizers and facilitators, responsible for the operation of the SIG and for communication and coordination with the other SIGs, the Technical Steering Committee, and the broader community. All SIG chairs are appointed by the Technical Steering Committee. If there are more than two Contributors being considered for a particular SIG, the Technical Steering Committee will vote on and resolve who the chairs would be. Candidates need to be Approvers.
Each SIG must have a charter that specifies its scope (topics, sub-systems, code repos and directories), responsibilities, and areas of authority. Charters are submitted to the MindSpore community via PR for review and approval by the Technical Steering Committee who will be looking to ensure the scope of the SIG as represented in the charter is reasonable. All SIGs are expected to follow the standards established by the Technical Steering Committee for how Contributors are roles of authority/leadership are selected/granted, how decisions are made, and how conflicts are resolved.
A primary reason that SIGs exist is as forums for collaboration. Much work in a SIG should stay local within that SIG. However, SIGs must communicate in the open, ensure other SIGs and community members can find meeting notes, discussions, designs, and decisions, and periodically communicate a high-level summary of the SIG's work to the community. SIGs are also responsible to:
mindspore-discussmailing list and/or IRC or slack or other channel.
When it is time to formalize the work-product from a SIG, votes are taken from every Contributor who participates in the SIG. The list of active Contributors is determined by the one (or two) SIG leads to ensure that only those who have actively participated in the SIG can vote. At this time there is no restrictions on how many Contributors from any one member entity can participate (and hence vote). The Technical Steering Committee will monitor how the community behaves and apply constraints if needed in the future.
While most work shouldn’t require expensive coordination with other SIGs, there will be efforts (features, refactoring, etc.) that cross SIG boundaries. In this case, it is expected that the SIGs coordinate with each other and come to mutually agreed solutions. In some cases, it may make sense to form a Working Group for joint work. Cross-SIG coordination will naturally require more time and implies a certain amount of overhead. This is intentional to encourage changes to be well encapsulated whenever possible.
Working Groups (WGs) are primarily used to facilitate topics of discussion that cross SIG lines, or are topics which are short-lived and require a limited set of decisions to be agreed upon. Working groups:
Working Groups can create glue code, specifications, recommendations, or implementations for submission to the relevant SIGs for approval and acceptance. At time of inception of this organizational structure, the following WGs will be present initially:
Working Groups are formed by submitting a proposal via PR to the Technical Steering Committee. The proposal should cover:
All repositories under the MindSpore org:
Repositories can be removed when they are inactive by archiving them.
All Contributors must either sign the MindSpore ICLA, or download and sign the MindSpore CCLA and sent a scan copy to firstname.lastname@example.org. The Technical Steering Committee will update the CLA to reflect the MindSpore organization/ownership as needed.