[openstack-dev] [openstack-tc] use of the word certified

Eoghan Glynn eglynn at redhat.com
Mon Jun 9 19:17:09 UTC 2014



> >> So there are certain words that mean certain things, most don't, some do.
> >>
> >> If words that mean certain things are used then some folks start using
> >> the word and have expectations around the word and the OpenStack
> >> Technical Committee and other OpenStack programs find themselves on the
> >> hook for behaviours that they didn't agree to.
> >>
> >> Currently the word under discussion is "certified" and its derivatives:
> >> certification, certifying, and others with root word "certificate".
> >>
> >> This came to my attention at the summit with a cinder summit session
> >> with the one of the cerficiate words in the title. I had thought my
> >> point had been made but it appears that there needs to be more
> >> discussion on this. So let's discuss.
> >>
> >> Let's start with the definition of certify:
> >> cer·ti·fy
> >> verb (used with object), cer·ti·fied, cer·ti·fy·ing.
> >> 1. to attest as certain; give reliable information of; confirm: He
> >> certified the truth of his claim.
> >> 2. to testify to or vouch for in writing: The medical examiner will
> >> certify his findings to the court.
> >> 3. to guarantee; endorse reliably: to certify a document with an
> >> official seal.
> >> 4. to guarantee (a check) by writing on its face that the account
> >> against which it is drawn has sufficient funds to pay it.
> >> 5. to award a certificate to (a person) attesting to the completion of a
> >> course of study or the passing of a qualifying examination.
> >> Source: http://dictionary.reference.com/browse/certify
> >>
> >> The issue I have with the word certify is that it requires someone or a
> >> group of someones to attest to something. The thing attested to is only
> >> as credible as the someone or the group of someones doing the attesting.
> >> We have no process, nor do I feel we want to have a process for
> >> evaluating the reliability of the somones or groups of someones doing
> >> the attesting.
> >>
> >> I think that having testing in place in line with other programs testing
> >> of patches (third party ci) in cinder should be sufficient to address
> >> the underlying concern, namely reliability of opensource hooks to
> >> proprietary code and/or hardware. I would like the use of the word
> >> "certificate" and all its roots to no longer be used in OpenStack
> >> programs with regard to testing. This won't happen until we get some
> >> discussion and agreement on this, which I would like to have.
> >>
> >> Thank you for your participation,
> >> Anita.
> > 
> > Hi Anita,
> > 
> > Just a note on cross-posting to both the os-dev and os-tc lists.
> > 
> > Anyone not on the TC who will hits reply-all is likely to see their
> > post be rejected by the TC list moderator, but go through to the
> > more open dev list.
> > 
> > As a result, the thread diverges (as we saw with the recent election
> > stats/turnout thread).
> > 
> > Also, moderation rejects are an unpleasant user experience.
> > 
> > So if a post is intended to reach out for input from the wider dev
> > community, it's better to post *only* to the -dev list, or vice versa
> > if you want to interact with a narrower audience.
> My post was intended to include the tc list in the discussion
> 
> I have no say in what posts the tc email list moderator accepts or does
> not, or how those posts not accepted are informed of their status.

Well the TC list moderation policy isn't so much the issue here, as the
practice of cross-posting between open- and closed-moderation lists.

Even absent strict moderation being applied, as hasn't been the case for
this thread, cross-posting still tends to cause divergence of threads due
to moderator-lag and individuals choosing not to cross-post their replies.

The os-dev subscriber list should be a strict super-set of the os-tc list,
so anything posted just to the former will naturally be visible to the TC
membership also.

Thanks,
Eoghan



More information about the OpenStack-dev mailing list