Anyone with a github ID can be a Contributor to the Baseline Protocol, but you can also become a Member of our Github Organization, which will allow you to get invitations to key meetings, be assigned to Issues, and vote for Technical Steering Committee members (provided you make at least one contribution that is successfully merged to master within the voting period).
Being a Member gives you Write access to the Github Repo as well as the Zenhub extension.
Members can manage Issues in pipelines, assign others to Issues, create Epics and Milestones and push contributions to any unprotected branch other than Master/Main.
It's a good idea to become a member if you are making regular contributions and want to be assigned Issues, be responsible for assigning Issues to others, or both. Members can be technical contributors, contributors to specifications, or people stepping up to be accountable for projects.
Joining the Baseline Protocol as a Member is easy.
Technical contributors should contribute at least one pull request. Then, use the #github-membership-requests Slack Channel to post your github ID, name and company (optional) and a coordinator will ensure that you are added as a member within 24 hours or less. If you do not receive a response in that time, use one of our chat channels to contact the TSC Chair and/or any member of the TSC to expedite.
To be a Member, you must of course sign the eCLA/iCLA. This is essential, because you have Write access to the repo, and OASIS governance requires that content be contributed under those agreements.
Non-technical contributors, and in particular those who wish to be on the General Assembly, do not need to submit a pull request. See General Assembly for details.
Trust is essential for members, because any member has the ability to make significant and direct changes to anything other than the Master branch or otherwise protected branches.
Members should:
show commitment by stepping up to contribute to key projects
be reliable in completing issues to which they have been assigned
attend regular member meetings when possible
follow the project style and testing guidelines
show an understanding of the nature and focus of the Baseline Protocol
be welcoming to others in the community
follow branch, PR, and code/docs style conventions
Of course, all members must respect and adhere to the community's code of conduct.
Any member may request a confidential review of another member to determine whether that member should be removed by contacting any TSC Member. TSC Members and any others engaged for such a review are expected to act with the highest professionalism, work in strict confidence, and keep the identity of the requesting member confidential.
Once you are a member, you can:
Become a Core Developer responsible for governing the contributions that get merged to the official master branch;
Get elected to the Technical Steering Committee, accountable for architecture and governance of the core developers;
Join the General Assembly accountable for proposing, prioritizing, and promoting Baseline Protocol projects.
Or, just write awesome code, specifications, docs and communications.
All work of the Baseline Protocol initiative is maintained publicly on a github repo.
You don't need any special access to the repo to get involved and start contributing. Follow these steps to fork the repo and submit pull requests. Anyone with a Github ID can also create and edit their own Issues, participate in public meetings, and join the various communication and collaboration channels that the community maintains.
There are four ways to contribute:
Write code (Architecture, Spikes, Issues, Tasks)
Write specifications (Epics, Stories, Prioritizations, Use Cases)
Write content and communicate it to more potential contributors, developers and product owners, and other stakeholders -- Join the communications team on Slack
Help prioritize work and develop incentives to get it done by joining the General Assembly or becoming a Core Developer or TSC Member.
There is one other way to contribute, and it's the most important: use the work in the Baseline Protocol to improve your own offerings. The Baseline Protocol is not a product or platform..the product is YOUR product.
Here is the link to the Baseline Protocol code of conduct:
Technical contributors either are working on architecture or developing code...but even correcting the language of documentation counts as a technical contribution and qualifies you to vote in upcoming TSC elections.
As of October 1, 2021, the baseline community will organize work in a similar fashion to Ethereum's EIPs (Ethereum Improvement Proposal). These will be called BaseLine Improvement Proposals, or BLIPs for short, and they will be maintained here. YOU ARE ENCOURAGED TO SUBMIT IDEAS to the BLIP repo, and we are well-organized to review and act on them in a timely fashion. You never know -- we might decide to raise a grant to pay for your idea to get executed. It's happened before. Try it out!
Technical tasks are written as Github Issues. Issues will be reviewed, lightly prioritized, and communicated as "hey, help out here!" messaging to the developer community every two weeks. The TSC will periodically review what Issues and communications best succeeded in attracting help.
An Issue should be constructed, in particular, with acceptance tests. All other elements of a good Issue should be known to any practicing developer.
Most Issues should be attached to an Epic (see below).
A good Task/Issue starts with a Verb: "Implement xyz."
Follow these steps when submitting a pull request:
Fork the repo into your GitHub account. Read more about forking a repo on Github here.
Create a new branch, based on the master branch, with a name that concisely describes what you’re working on (ex. add-mysql).
Ensure that your changes do not cause any existing tests to fail.
Submit a pull request against the master branch.
Good practice strongly favors committing work frequently and not loading up a long period of work in isolation. Be brave...let others see what you are working on, even if it isn't "ready."
Anyone can do a pull request and commit work to the community. In order for your work to be merged, you will need to sign the eCLA (entity contributor agreement) or iCLA (individual contributor agreement). Here are the details: https://www.oasis-open.org/resources/projects/cla/projects-entity-cla
The iCLA happens automatically when people submit a pull request, or they can access directly by going to https://cla-assistant.io/ethereum-oasis/baseline
Merging to Master requires review by THREE Core Developers. The TSC seeded the initial set of Core Developers. Now, any active Member can become a Core Developer. Core Developers may add more Core Developers by rough consensus, and the TSC may step in to resolve cases where this process fails.
The specifications work of the community can be done by anyone, both technical and non-technical contributors. The focus is on finding evidence for a requirement and articulating it in the form below. The General Assembly is the coordinating body for this work.
The Baseline Protocol initiative uses Zenhub to create and manage both specification work and active protocol requirements and prioritization. (Zenhub should be a tab in your Github interface if you are using the Chrome extension. There is also a web-app here.)
Zenhub enables Epics to nest, while Issues don't nest...not really. Therefore, the community will employ the practice of using Issues for engineering Tasks and Epics to contain high level topics, which may have nested within them a set of agile Epics, and in them a set of Stories, and even Stories may have other Stories nested in them. Engineering meets planning where a Story (in the form of a Zenhub Epic) is referenced by an Issue/Task. (This can work very well, but Zenhub's choice in calling Epics, Epics can cause confusion.
A Zenhub "Epic" used as a high-level container for a grouping of work should be in short topic form -- primarily nouns.
A Zenhub "Epic" used as a Story should almost always follow the form: "As X, I need Y so that I can Z." An acceptable variant is the "now I can" form (note the "so that" clause is preserved):
A Party's System Administrator can look up Counterparties in an OrgRegistry (a public phone book) and add them to a Workgroup, so that they can start Baselining Records and Workflows.
A Party's System Administrator can quickly and easily verify a Counterparty's identity found in the OrgRegistry, so that they can be confident in adding the Counterparty to a Workgroup.
A Party's System Administrator can use some or all of the Counterparties and Workflow Steps defined in one Workgroup in Workflow Steps created within another Workgroup, so that Workgroups don't become yet another kind of silo.
The active contributors and maintainers of the Baseline Protocol repo can be found on Github. (Note: many contributors work in clones extending the protocol for their products. These people don't necessarily show up in the Github contributors list.)
The Baseline Protocol initiative was announced on March 4, 2020 and launched as an OASIS open source project on March 19, 2020, supported by fourteen founding companies. The number of active companies and individuals contributing to the work and using it in products and enterprise solutions grew quickly through the Summer of 2020 and currently is estimated at over 600.
The initiative is strongly aligned with the Mainnet Working Group, a joint effort of the Enterprise Ethereum Alliance and the Ethereum Foundation.
This work is active and open to contributors.
All work in the Baseline Protocol public repo is released under the CC0 1.0 Universal public domain dedication. For the full license text, refer to license.
In an openly governed open standards / open source initiative, leadership is organic. One need not be seated to a committee to lead. One need not be the chair to lead the community in a direction. (Indeed, the chair's primary job is to harmonize the interests of others and help the community move to a shared vision, not necessarily to forward their own point of view.)
The way to lead is to start something, help something, fix something...even spellcheck something! The way to lead is to get others to amplify what you are doing (best done by listening deeply to others first). The way to lead is to serve your own (and your company's) enlightened self interest. You should be able to draw a straight line from your time on this work to real impact for your own offerings.
Below are the things you need to know to get informed, get involved and get value out of the work.
Anyone can join the Baseline Protocol communication channels (see below), and anyone with a Github ID can view the roadmap (don't forget to log in with github id), fork the repo, and submit pull requests to contribute to the work.
You can also become a regular Member of the initiative, which will allow you to manage Issues and push directly to most repo branches (other than Master). Members who step up to be accountable for projects can become General Assembly members. Members who take on responsibility for maintaining the integrity of the work and merging contributions to the master branch of the repo can become Core Developers. And finally, contributors can nominate and vote-in members to be on the governing Technical Steering Committee (TSC) annually.
Below are the things to know about how to get involved and work with the team.
There are regular meetings of the TSC, General Assembly, Core Developers and other groups. These are typically listed here. If the times we have don't work for your timezone, we can do 1-1's or make changes to the schedule.
It's critical that new contributors have a good idea about what the focal points of the community are and where one can make a real impact. It's hard to beat having a real conversation about how to get started in an intimate setting where you can ask questions and get immediate answers.
We will hold Onboarding office hours once a week. Watch the Calendar for details or inquire on one of the communication channels below. Sessions and other learning material will be posted on our YouTube Channel and on Medium.
The TSC meets typically once a month to review progress. Members of the TSC receive invitations and you can rsvp to join any meeting by sending a message to the TSC Chair.
The General Assembly meets typically once a month to review roadmaps and set high-level priorities. Members of the General Assembly receive invitations, and you can join any meeting by sending a message to the TSC Chair.
The Baseline Protocol initiative maintains a Slack channel that is moderated but public. Sign up here. It's an active group, and you can directly connect with folks doing the work and coordinate with each other to get the work done.
Thanks to an enterprising member of the community, we now also have a shared Matterbridge-enabled channel between Slack, Telegram, and Discord. You can post -- and read what anyone posts -- on the shared channel, regardless of which platform you are using. In Slack, use the #community-chat channel to broadcast to Slack, Discord and Telegram. In Discord, use the #general channel. In Telegram, just use the main /baselineprotocol thread.
You can sign up to the baseline protocol members list and get access to the Directory. This will show you any members who have elected to be displayed publicly. There are others who will choose to be hidden but will receive group emails.
While most communication seems to go through the Slack/Discord/Telegram channel, we do have email. When you sign up in the members directory, you will have the option to get email that's sent to the mailing list or directly from anyone in the group. You can control how that impacts your inbox here.
The Baseline Protocol initiative is launching soon a Discourse forum. Reddit is also likely. We also actively use commenting on Epics and Issues to conduct threaded discussions on key projects and engineering topics. To View the Zenhub Board for these, sign into Github with your ID, or you can install the Zenhub plugin to your Chrome browser and sign in that way. If you are member of the Ethereum-Oasis Org.
The Baseline Protocol initiative maintains the @baselineproto Twitter account, to which members of the TSC, General Assembly and some maintainers can post. We also use the #baselineprotocol tag.
The Baseline Protocol initiative uses Medium to post blogs. Here is the publication. Reach out on Slack to the TSC Chair, OASIS team or members of the steering committees, if you want to be a writer or editor.
The Baseline Protocol initiative maintains a YouTube Channel. If you have videos that you'd like to add to the Channel or would like to help on Baseline Protocol video assets, use the Slack #comms-and-marketing channel and raise your hand.
