[yocto-ab] YP Advisory Board: YP Compatible changes

[Osier-mixon, Jeffrey]

> It has been suggested that I spell out what I would like to see.
> I did this a bit in the call the other day but it is unreasonable of me to
> expect anyone to remember that.  The following is more detailed
> anyway.

Thanks, Bill. Unfortunately we rarely get a quorum at meetings these
days, so many people missed the discussion. I appreciate the work you
did to write this up.

My comments below.

> I would like to see something like this:

I have to LOL, because this looks more draconian than what I put
together earlier!  :)

> 1) Yocto Project Compatibility will continue to be per Yocto Project
> release, even when originations are self certifying.

Yes, that aspect of the program was not intended to change

> 2) Anyone can raise a compatibility concern.  (bugs.yoctoproject.org?)
> The layer owner should be included on the problem report.  The
> architecture team, lead by Richard, has sole responsibility to decide
> if the issue is one that requires this process to be followed.

Seems reasonable

> 3) Any issue verified by the architecture team needs to be fixed before YP
> Compatible is claimed for the project release on a later YP release.
>
> If an issue if found in MyOS 45 based on YP 1.7, then it needs to be fixed
> before MyOS based on YP 1.8 can be claimed to be YP compatible.

...or MyOS 46?

> 4) It is highly desirable (required?) to fix or document as a compatibility
> errata for the current release.

I'd say that would be determined by RP, and depends on how large a
problem it actually is. That being said, it seems to me that
documentation and/or a patch is a very reasonable way to resolve a
current problem. As you said earlier, we really don't want to mandate
anything in a branding program that might break things for existing
users, and we don't want to screw the submitting organization either.

> MyOS 45.1 should include a fix if it won't hurt users of MyOS.
> If the fix is too disruptive it should be included as an errata notice
> in someway.  Suggested workarounds should be supplied when practicle. Choice
> of resolution is left to the layer owner.
>
> Timeframe?
>    Commercially reasonable
>    as soon as reasonable but not to exceed 6 months
>    etc.
>
> 5) It is expected that all YP members follow these rules in good faith and
> no branding rights will ever need to be revoked once granted.  If the
> need does arise, branding rights can be stripped from an organization
> or project by a 2/3 majority vote of all current YP members (silver ==
> 1 vote, gold == 2 votes).  If branding has been revoked, the
> organization or project can reapply for branding and it will be granted
> provided all issues have been resolved.

I would be very concerned about revoking branding rights from any
member organization, or in using or altering the Advisory Board's
voting system to do so. I can see the value in defining the power of
the Board in this way, but we do have to remember that all members act
in good faith, and that for the past 3 years we have done so to a very
high functioning level. The Board currently has this ability based on
a simple majority, or at least that is my understanding of the current
rules.

I would maybe add a statement that revoking these rights does not
affect existing YP Compatible status, and that this only revokes the
organization's right to assign YP Compatible to its own products. In
essence, it downgrades them back to our current system, where every
status must be voted in by the board. It does not remove their ability
to put that status on new layers/products/releases, or affect their
printed material for existing releases.

I would very much like to hear others weigh in on this.

> ********
>
> What this does:
> * Put the focus for fixes on future work
> * Focus for current work is knowledge of the issue
> * Ensures one picky person can not torpedo a ton of marketing work or
> invalidate physical material
> * Allows an intentional bad actor to loose branding

I think we can work with these concepts.  I'll try to summarize in the
working draft rules below.

_____________________________________________

I have snipped most of the message below and kept just the proposal,
editing to fit Bill's ideas.

Goals:

>>>>> - to minimize the "rubber-stamp" Advisory Board votes required for each
>>>>> release
>>>>>
>>>>> - to offload from the technical team the responsibility for verifying
>>>>> each new release
>>>>>
>>>>> - to empower the sponsoring organizations with the responsibility for
>>>>> maintaining their own branding while keeping overall control with RP
>>>>> and the Advisory Board

add:

- to empower RP and/or the Advisory Board to cope with bad actors or
others not acting in good faith, where good faith here is defined as
"acting in the best interest of both the group and the individual" -
specifically, retroactive punishment will not be allowed, and the
needs of the users come first

- to focus on current and future work in order to better align layers
and products with the precepts of the project

>>>>> To summarize the changes:
>>>>>
>>>>> 0 - I will work with RP to create specific guidelines for member orgs
>>>>> to follow regarding what can be considered YP Compatible and what
>>>>> can't. I will also work on the existing messaging to clarify the
>>>>> program better.
>>>>>
>>>>> 1 - Going forward, layers or products only need to be voted in once.
>>>>> After that, the onus is on the sponsoring organization to make sure
>>>>> the layer stays within the guidelines. YP Compatible items from
>>>>> non-member orgs will keep the existing rules.
>>>>>
>>>>> 2 - Every time YP or the item itself is released, the sponsoring org
>>>>> must fill out a form verifying that the YP Compatible item still meets
>>>>> the guidelines.
>>>>>
>>>>> 3 - If anyone complains that a product or layer does not meet the
>>>>> guidelines, RP's organization and I will investigate and recommend
>>>>> changes or remove it from the list. It is incumbent on the sponsoring
>>>>> organization to fix any problems that arise.

change #3 as follows, summarizing Bill's ideas above:

3 - If anyone complains that a product or layer does not meet the
guidelines, RP's organization will investigate and work with the
sponsoring organization to recommend changes for future versions, and
to potentially publish errata or patches for the existing version.

potentially add something like this:

4 - The Advisory Board can revoke a member's right to assign its own
YP Compatible branding with a 2/3 majority. Existing YP Compatible
layers/products are not affected, but the organization must then apply
for an Advisory Board vote for any new layers, products, or releases
until their assignation rights are reestablished by RP's advice and by
the Advisory Board with a 2/3 majority. This is intended only to
address repeat bad actors for the good of the project.

Bill, does that address the issues you are concerned about?

I have no doubt that we will continue to find issues that are either
undefined or ill defined, and we will have to work those out in good
faith. The organizations on the project may not all be business
partners, but we all benefit directly from refining these ideas and
rules for the greater good of the project.

<snip>

> I am actually very encouraged that we are moving toward a system where we
> all get more compatible as we learn from each other best practices for our
> layers and our QA checks.

If the YP Compatible program is able to help accomplish better
alignment, it will be achieving its highest aspirations.


-- 
Jeff Osier-Mixon @Intel
Yocto Project Community Manager http://yoctoproject.org