|
Dear members,
I don't think OSLC MS was ever CCed on any of the Open Project Proposal emails.
/A
Begin forwarded message:
Subject:
[oslc-core] OASIS OSLC Open Project Proposal
Date:
17 December 2018 at 19:13:37 CET
The OASIS OSLC Membership Steering Committee (StC) proposes to migrate the current OASIS OSLC standardization activities to a new OASIS OSLC Open Project. The purposes of this migration
are to:
* Engage a broader community in OSLC technical work by allowing participation and contribution from non-members without incurring dues or fees
* Increase OSLC adoption by encouraging more contribution, awareness and users
* Provide a context in which to develop related work products including open source reference implementations, sample applications, and other collateral that expand and complement the OASIS Standards
track documents
* Simplify the infrastructure and processes for developing OASIS Standards
* Reduce fragmentation in the OSLC community by providing a central, world wide, respected organization in which to develop OSLC related work products
Specifically, the StC proposes the following:
1. Utilize the current StC members to form the initial OSLC Project Governing Board (PGB), retaining the current chair
2. The current Core and Domains TC members are merged and become the initial OSLC Technical Steering Committee, retaining the current chairs and cochairs.
3. The existing OSLC Core and Domains GitHub repositories will be migrated as is to the OSLC Open Project
4. The existing OSLC4JS project will also be migrated to the OSLC Open Project and will provide a code base that establishes a Statement of Use of the OSLC Standards and a code base for exploring
and validating proposed changes to the standards
5. The existing eclipse/Lyo Open Source project at
eclipse.org will remain unchanged in order to leverage the eclipse governance process and Type B due diligence.
This proposal is subject to approval by the StC, with the decision scheduled to be addressed at the next StC meeting, Jan 21, 2019.
In order to facilitate the decision process, the StC would like clarification on the following questions.
1. What exactly are the Open Project fees and who pays them?
1.1. What are the startup and annual fees for an Open Project?
1.2. It is our understanding that the PGC requires a minimum threshold in annual sponsorship commitments by OASIS member companies. What is this minimum threshold?
1.3. What are OASIS members of the PGC expected to contribute to the Open Project fees?
1.4. What is the relationship between the OASIS member dues and Open Project fees?
That is, if an OASIS member company participates in many Open Projects that develop different OASIS Standards, will the member company have to pay OASIS membership fees as well as additional fees
for each Open Project for which they are PGC members?
1.5. What happens of the member participation in the PGC falls below the minimum threshold, but there is still ongoing work by the Technical Steering Committee in the open source and/or specification
deliverables?
2. What are the rules for non-member participants, contributors, maintainers and PGB members?
2.1. Do non-members of either the Technical Steering Committee or Project Governing Board have voting rights?
2.2. How are these voting rights calculated? At the discretion of the PGB?
2.3. Do all voting members have to sign the CLA (even if they don't contribute content)?
3. Regarding Legal entity, oversight, management of IP and licensing agreements, trademarks and copyrights: Specifically what services will OASIS provide in order to assess the IP of Open Project
work products, including dependencies on components outside the project?
For example, open source projects often have dependencies on other open source projects. In order to assess IP exposure, it is typically necessary to examine all direct and transitive dependencies
to ensure there are no licensing issues. This often requires code scans to detect potential issues. Will OASIS provide these services?
4. Will the current OSLC TC GitHub repos, wikis and issues be migrated as is to the new open project?
4.1. Will there be any impact on existing TC work products?
4.2. Will the open project specification template be different than what is currently being used by the OSLC TCs, and automated through ReSpec? We are trying to minimize spec rework and ReSpec updates.
4.3. The Open Project specification lifecycle appears to require statements of use before public review. What are the implications for OSLC Domain and Core TC documents that are already in progress?
4.4. Are there any changes in how Open Project standards track work products are published by OASIS?
Specifically I'm trying to understand if the issue we had with document relative links being broken by the OASIS publishing process will be resolved by migrating to an Open Project so that we don't
have do the work to modify ReSpec to fix up links on document publish.
5. What are the hosting constraints and any additional costs associated with utilizing the Open Project Web site?
We have just deployed a new
open-servicers.net site. This site was developed using HUGO (https://gohugo.io).
Can we continue using this technology and URL for the Open Project web site? Note that it is necessary to preserve the
open-service.net domain since the OSLC namespaces utilize this domain name for backward compatibility and access to machine readable vocabulary documents.
Jim Amsden, Senior Technical Staff Member
OSLC and Linked Lifecycle Data
919-525-6575
|