oslc-core message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: OASIS OSLC Open Project Proposal
- From: "Jim Amsden" <jamsden@us.ibm.com>
- To: oslc-sc@lists.oasis-open.org, "TC Administrator" <chet.ensign@oasis-open.org>, "Scott McGrath" <scott.mcgrath@oasis-open.org>, "Carol Geyer" <carol.geyer@oasis-open.org>
- Date: Mon, 17 Dec 2018 13:13:37 -0500
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]