Clarify ORAS is not an OCI project

[sudo-bmitch]

Based on discussions in ORAS/artifacts-spec #96 and ORAS/artifacts-spec #88, I think the wording in the readme gives the false impression that ORAS/artifact-spec is being used as a staging ground for future changes to this or other OCI specs. This clarifies they are their own project developing their own spec separate from the working group.

Signed-off-by: Brandon Mitchell git@bmitch.net

[michaelb990]

How about one of these instead?

Suggested change

- There also exists [oras-project/artifacts-spec repository][oras-artifacts] that is not part of OCI or the above working group.

or

Suggested change

	- There also exists [oras-project/artifacts-spec repository][oras-artifacts] that is not part of OCI or the above working group.
	- There also exists [oras-project/artifacts-spec repository][oras-artifacts] which has submitted [Proposal A](https://github.com/opencontainers/wg-reference-types/blob/main/docs/proposals/PROPOSAL_A.md) to the above working group.

[mikebrow]

I like the second edit, let's see if we need subjective comments about any of the other oci compatible / related artifact manifest/refers projects, then see if we still want this change. Cheers, Mike

[mikebrow]

ok.. thx for the suggestions see new readme and reopen / rebase if you think we need more changes :-)

[imjasonh]

FWIW I don't think the recent change in #57 does much to address the original goal of this PR.

[sudo-bmitch]

Yeah, reading the readme, I'm left with the impression that OCI is considering both the working group output, and ORAS equally. We should either remove ORAS or add all of the other projects implementing methods to push artifacts to avoid playing favorites.

[mikebrow]

a couple reminders from the oci tob charter quoted without comment:
The Open Container Initiative does not seek to be a marketing organization, define a full stack or solution requirements, and will strive to avoid standardizing technical areas undergoing innovation and debate.

iii. there will be a strong bias to exclude items from the specification in technical areas undergoing significant innovation and debate, especially if those areas are likely to be the basis of differentiation between competing implementations.

or add all of the other projects implementing methods to push artifacts to avoid playing favorites.

@sudo-bmitch I like your idea about adding/listing all other projects (artifacts related) in the Related Projects Working on Extending OCI Specs section.. that's more than fair, and proper I think.