Home
ODPi SIGs are modeled on the W3C Community and Business Groups and are meant to provide a less formal forum for ODPi developers, bigdata practitioners and industry stakeholders to explore ideas and influence the roadmap of the ODPi.
SIGs are similar to PMCs in that they operate under the governance of the TSC, but unlike PMCs that have a formal commitment of the biannual ODPi release, SIGs are only expected to produce an informal report twice a year.
A lot of times SIG scope and charter will ultimately be adopted by either an existing or a new PMC and continue on. However this is not a requirement and we also envision long running SIGs that keep producing their reports along side the ODPi release activities producing test suites, white papers, demos, or merely holding discussions.
All it takes to have a SIG is a good idea and somebody willing to run with it. Interested? Read on!
Click on each SIG to find out membership, meeting times and browse through meeting notes
All current SIGs are open for new members to join. By default SIGs are using odpi-technical mailing list for all on-line communications between the SIG members. This means that all you have to do to join a SIG is drop an email to the odpi-technical mailing list, introduce yourself and briefly describe why are you interested in the SIG activity. Include your GitHub ID in the introductory email so that a SIG Champion can add you to the GitHub group. That will allow you to edit wiki and update any kind of artifacts that SIG members are collectively maintaining on GitHub.
If you would like to propose a new SIG - read on!
If you think that there's an interesting area in the landscape of bigdata that ODPi is currently not addressing directly - congratulations! You've taken the first step to proposing a SIG. You don't have to fill any kind of standard template for your proposal -- just send an email to odpi-technical@lists.odpi.org detailing with a title and short summary. A proposed SIG description should be detailed enough to help people decide whether they would like to participate. At the very least it should include a brief mission statement and goals for the SIG.
Every SIG must have a champion. There's no requirement that if you're proposing a SIG you automatically sign up to champion it. If your proposal is exciting enough you may have other experts who would be willing to champion it. Still, since the SIG can not exist without a champion make sure to clearly state in your proposal whether you're willing to take on those responsibilities.
SIGs can be proposed anytime, but since, at the very minimum they expect to produce a report as part of semiannual formal ODPi releases the best time to propose a SIG is during the upcoming release planning cycle.
After a SIG is proposed on the ODPi technical mailing list the next phase is a discussion process culminating by an approval process by the TSC. All it takes to get onto the TSC radar for approval is to add your proposal to the upcoming agenda and join the meeting. Since TSC is guided by the consensus of a technical community you're strongly encouraged to provide links to the discussions on the ODPi technical mailing list that are relevant to your SIG proposal. Also, remember, that while an initial SIG proposal doesn't have to have a champion, TSC will only consider SIG for approval if it does have a designated champion by the time a proposal comes up for a TSC consideration.
After a SIG gets approved by a TSC it is considered operational and will be expected to produce a report as part of the upcoming ODPi release. As any release work, this is tracked by an umbrella issue recorded in the ODPi JIRA and committed to the next ODPi release version. SIG members start with having access to the same set of collaboration tools that PMCs have access to:
- ODPi GitHub
- ODPi GitHub wiki
- ODPi technical mailing list odpi-technical@lists.odpi.org
It is up to the SIG's champion to request additional resources (such as dedicated mailing lists, etc.) as needed. It is recommended that a SIG champion establishes a regular syncup (in form of a con-call or a hangout) with the rest of the group to
SIGs are currently expected to produce reports as part of the biannual ODPi release cycle. The reports can be accompanied by any number of additional release artifacts such as validation testsuites, documentation and anything that a group can think of but reports are a must. A SIG report is expected to be a documented checked into the SIGs GitHub repo and tagged for a release. A report needs to details SIG findings and recommend additional course of action. After each release TSC is expected to review all of the SIG reports and act according to their recommendations.