> >> 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 _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
