Once you've done some work as a Member, you may wish to become a Core developer and have a direct hand in deciding what work is merged to the Main/Master Branch to become official Baseline Protocol technology and specifications.
Here's a list of current Core Developers.
Core developers are people who take an active role in advancing the Baseline Protocol and/or related projects. They are primarily responsible for:
Contributing code or contributing to specification work in the form of PRs that are linked to open and prioritized issues
Reviewing and merging PRs into the master branch
Cutting, testing, and releasing new versions of the related Baseline projects
Working with the TSC and General Assembly to advance the Baseline Protocol
They can/should also contribute in the following ways:
Writing epics and issues to guide development
Setting up and supporting infrastructure (running demos, CI systems, community projects, etc...) that further Baseline
Working with the community to help with adoption
Presenting the project and key technologies to the public (in-person, webinar, videos, articles, etc...)
There are two ways to become a core developer: You are asked by a current core developer, or you make request to an existing core developer to become one.
With either path you become a "provisional core developer". As such you will need to show consistent contributions of code and/or specifications to the project. This can be in the form of pull requests that get merged into master. Or it can be in the form of technical specification, system architecture and related artifacts that guide the development activities of others.
All provisional core developers that focus on code development (over standards) must meet with the existing core developers and demonstrate they are capable of the following:
Running the project locally
Using the testing framework
Explaining the components of the system architecture
Walking through the code and explain the baseline process
Once the provisional core developer demonstrates their capabilities, the existing core developers will vote during the next scheduled core developer meeting to give the prospect full core developer status. Members must vote with 2/3rds majority to add a core developer. Voting that results in a tie or potentially other issue will be brought to the TSC for review.
In general, a core developer needs to:
be an expert in one or more fields related to the project
be an expert in finding and engaging the advice of other experts
show commitment over time with multiple PRs merged
be reliable in completing issues to which they have been assigned
attend the weekly core developers meetings (with occasional absences allowed)
demonstrate competency in software development or specification writing
follow the project style and testing guidelines
have a high degree of understanding of the project architecture
be welcoming to others in the community who are using the project
contribute in ways that substantially improve the quality of the project and the experience of people who use it
follow branch, PR, and code style conventions
Core Developers meet and discuss issues virtually via the #maintainers slack room in the baseline slack.
There are weekly Core Developers meetings where members can discuss plans and issues related to the project, updates, release planning, and other related topics. Anyone may attend these meetings, but the primary participants are core developers. Core developers are required to produce meeting summaries and document decisions.
Meeting signups are maintained on the "Join the Community" page on https://baseline-protocol.org.
Any of the following ways:
You stop reviewing PR's, responding to messages, answering emails, and/or generally ghost the project.
You are disrespectful towards anyone in the community and/or involved in the project.
You are disruptive to the general process of maintaining the project, meetings, discussions, issues, or other.
You notify the other core developers you would like to relinquish your core developer status.
Two-thirds of all current core developers constitute a quorum for a meeting involving a question of removal. A simple majority vote from core developers attending the meeting is required to remove a core developer, but the TSC may be brought in to arbitrate if the core developer to be removed or any other core developer wishes to dispute the action. (See Governance for details.)
The General Assembly is a regular meeting of community members.
Meeting signups are maintained on the "Join the Community" page on https://baseline-protocol.org.
Identify high-level baseline protocol project categories
Articulate specific projects within those categories for the community to execute
Rank projects by loose consensus so that contributors can spot attractive opportunities to work on
The group meets monthly (or biweekly, as needed) and is convened by the TSC Chair. From an OASIS governance perspective, the General Assembly is considered a subcomittee of the TSC, but in practice, the General Assembly and TSC have coequal roles in the community.
Baseline Community Projects are the General Assembly's way of managing specific objectives for the baseline protocol initiative. General Assembly members commit themselves to one or more of these.
To be an General Assembly member means you are standing up -- alone or with a group of members -- to be accountable for one or more projects of the Baseline Protocol Initiative.
While others may do the development and task-work, a General Assembly member commits to articulating and prioritizing the work, identifying community members and others who can do the work, and using whatever incentive structure is available (or whatever influence one has) to help ensure the work gets done.
General Assembly Members also keep the community of project stakeholders regularly informed of status. This includes cases where milestones aren't being met or when a project should be shut down and the learning recycled into another project.
Here's a snapshot of the project roadmap in the baseline protocol's Zenhub dashboard:
Projects can be technical, strategic, or organizational. For example, a technical project would be finding a messaging system that suits the baseline specifications. An organizational project would be developing a powerful and flexible incentive structure for the baseline community. Both are managed and tracked in Zenhub as shown above.
General Assembly Members have Github write permission, which gives them the ability to add and edit Projects, Epics and Issues, and to assign (and be assigned) work to specific Contributors.
Unlike the TSC, which is fixed at eleven elected members, the size of the General Assembly is flexible. To balance openness and inclusiveness with the need to keep the team manageable and accountable, there is a single rule that determines membership: Accountability for Active Projects.
If you want to help lead an existing project or if you intend to create a new project, post the following to the #SSC-membership-requests Slack channel (or optionally contact the TSC Chair directly):
Your name, email, company/organization, github ID
A one or two-sentence description of the area around which you intend to help provide leadership
You will receive back an invitation to either a special session of the General Assembly or the next general General Assembly meeting, and you may at that time state your intention to join the team. If no one asks for a further review by the TSC, you are approved as a new member of the General Assembly and can begin working on your Project(s).
General Assembly Members will be added to the Github Org, have Read access to the main Baseline Protocol repo and Write access to the Roadmap repo.
Within 24 hours of approval as a new General Assembly Member, you will be sent an email with instructions on how to get permissions to the various tools you now have at your disposal, including:
The ability to create and edit projects, epics and issues on Zenhub (Write access to the Github repo.)
The ability to post messages to community members
Invitations to the General Assembly meetings
To prepare for a great start to your time on the General Assembly, review the existing projects and top-level epics. Then get an idea where you want to focus your attention, and if it isn't represented in the dashboard, consider adding a Project or talk with other General Assembly members about it.
Just as getting into the General Assembly is about stepping up to lead on a project, leaving the General Assembly would be a natural process of ending those projects or cycling off leading them. The General Assembly will periodically do a house-cleaning segment in the regular meeting to achieve loose consensus on whether any projects require pruning.
General Assembly Meetings have these standard agenda items:
Review of new Projects
Triage of Projects that seem to need help
Ranking of "top featured" Projects that will be promoted by community influencers
Celebrate successful Projects and clean up list
Anyone in the member community can suggest agenda items for upcoming General Assembly meetings. Contact the TSC Chair.
Over 500 people and companies signed up to be notified about the opening of the Baseline Protocol Github repository between March 4th and 19th, 2020. Over 300 of them also signed in as group members. The members represent many of the largest companies in the world, spanning several sectors. They also represent startups, students and talented individuals.
*(In the mid-1990s, the Java community amassed thousands of developers from many companies before any of those companies officially sanctioned their involvement. Many of the companies participating in the Baseline Protocol initiative embrace the work, some already adding baselining to their strategic plans. But anyone observing someone's participation in the baseline community should assume that they do so as individuals. Please refrain from making assertions about the intentions of their employers.)
The project governance board (PGB) is organized by OASIS and is accountable for ensuring the balance and integrity of the Ethereum-Oasis initiatives, such as the Baseline Protocol.
OASIS employs key personnel that support all the open standards and open source projects under its domain. In addition, the Enterprise Ethereum Alliance maintains a team that also supports EEA Community Projects such as the Baseline Protocol. And finally, members such as ConsenSys have assigned key personnel specifically to support and organize the community.
Name
Organization
Claudia Rauch
OASIS
Carol Geyer
OASIS
Chet Ensign
OASIS
Paula Lowe
EEA
Lillian Guinther
EEA
Sonal Patel
ConsenSys
The technical steering committee (TSC) is accountable to the Project Governance Board for managing conflicts on merges and Core Dev self-organization. It also governs the allocation of grant money. And it meets regularly to set technical roadmaps and ensure progress of the community toward the ubiquitous implementation of the baseline protocol in systems of record everywhere.
On October 27, 2021, the following people were voted in as the TSC through October 2022 and the date of the next election's results.
Name
Company
End-Labs
ZK & L2 Leader, EEA L2 WG Chair
Golden Next Ventures
Unibright
SAP
WhitePrompt
EY
Microsoft
Provide
Unibright
ConsenSys Mesh
The Core Developers are a subset of the contributing members of the community who have demonstrated leadership and teamwork and approve all contributions before merging them to the Main branch of the repo.
Details on how to become a Core Developer here.
Maintainer (with link to Github ID)
Company
ConsenSys
Provide
EY
Provide
Nethermind
Consianimis
Finspot
WhitePrompt
N/A
The standards team worked through most of 2021 to develop a world-class technical specification that implementers and test developers can use to ensure compliance with the baseline protocol specification. The draft will now be shepherded through the OASIS process of review and amendments, culminating in becoming an official OASIS standard. Standards writing is hard, and reviewing the writing is equally hard. This team deserves the highest regard from the community for its hard-toiling service and commitment to excellence.
Member
Company
Anais OFranc
Consianimis
Andreas Freund
ZK & L2 Consultant
Kyle Thomas
Provide
Daven Jones
Provide
The outreach team consists of writers, evangelists, stakeholders, sponsors, events organizers and marketers who work together to develop enablement materials, promote baselining in the media, events and through direct engagement with thought leaders and decision-makers.
Member
Company
Melanie Marsolier
Splunk
Jack Leahy
Provide
Others being confirmed for listing
AMD, EY, ChainLink, Core Convergence, ConsenSys, Duke University, Envision Blockchain, MakerDAO, Microsoft, Neocova, Splunk, Unibright, Provide, and W3BCLOUD.
-- Co-Chair
-- Co-Chair