Policy-Discussion

[Guillaume ROMAGNY <guillaume AT cacert.org>]

Hello Ulrich, Hello All,

Your option is a virtuous circle and community oriented. Someone may be
missing at one point in time but the circle is not broken (aka too many
eyes in the loop). We remove a breaking point in the process this way.

Let's keep going forward on thoses ideas :)

Best regards,

Guillaume

Le 22/02/2013 01:50, 
ulrich AT cacert.org
 a écrit :
> the next thing to consider
> simple changes is still a pain, as main policies are located
> within the critical system, and we're currently blocked since 2009
> to update the main policies according to policy group decisions  :-P
>
> The simple way goes through filing a bug report and
> pass the changes via Software-Assessment
> (at least 2 software-assessors who did undergo an ABC process
> who checking the changes) and/or the critical admins
> (critical admins also did undergo an ABC process, so trusted personal)
>
> Since Oct 2012 we have an active Software-Assessment
> update cycle process so updates to the production system
> gets faster passed to the production.
> All changes will be checked based on the defined
> update cycle process by at least 10 eyes (!) principle
>  2 software-assessors
>  2 software-testers
>  1 critical admin
>
>  5 times 2 = 10 eyes ,-)
>
> This counts as an advantage that prevents
> going wild with unappropiate changes
>
> At least Arbitrators have to reread policies from
> time to time and will give notice that a policy
> requires an update according to the "minor changes"
> decision or rules, that a policy decision did not
> find its way under the main policy directory
>
> sample
> decision for RDL was given under p20100710
> https://wiki.cacert.org/PolicyDecisions#p20100710
>
> Two months later, we still discussed updates on CCA
> assuming we can make progress in a short time
> so the motion
> https://wiki.cacert.org/PolicyDecisions#p20101009
> Changes to CCA for RDL
> have been rejected   :-P
>
> Now, over 2 years later, we see, that our expectation
> to make progress with an CCA update failed :-P
> and the NRP-DaL definition is still in there
> that still have been replaced by RDL back in July 2010  :(
>
> With https://wiki.cacert.org/PolicyDecisions#p20100306
> p20100306 Policy Officer makes minor adjustments
> this can be easily corrected, but here we are again
> at the point where the cat bites its tail   :-P
>
>
>
> regards, uli    ;-)
>
> -----Original Message-----
> From: Guillaume ROMAGNY 
> [mailto:guillaume AT cacert.org]
>  
> Sent: Friday, February 22, 2013 12:35 AM
> To: 
> cacert-policy AT lists.cacert.org
> Subject: Re: improving p20100306 - minor changes (TRIAL POST)
>
>
> Hello,
>
> Reading the thread including the Herod analogy, I really believe, in
> case we don't have an appointed Policy Officer, *we* can be the
> *somebody*.
>
> Not a physical officer but a moral body. At least, one of us (hoping not
> always the same (*), considered as a temporary tasked oriented Policy
> Officer) can do the minor changes, so we don't turn to *nobody* style. I
> guess it is community oriented and "Ian style compliant"(tm). We avoid
> to wait for the Board to nominate someone.
>
> So, we become able to nominate a temporary PO.
>
> (*) Hoping to avoid :
>
> Go down, Moses,
> Way down in Egypt's land,
> Tell old Pharaoh,
> Let my people go.
>
> 0.02€
>
> Best regards,
>
> Guillaume
>
>
> Le 21/02/2013 18:45, Megan C. Robertson a écrit :
>> Greetings, dear hearts
>>
>> Once upon a time there were four people: Their names were Everybody,
>> Somebody, Nobody, and Anybody. Whenever there was an important job to
>> do Everybody was sure that Somebody would do it. Anybody could have
>> done it, but Nobody did it. When Nobody did it, Everybody got angry
>> because it was Everybody’s job. Everybody thought Somebody would do
>> it, but Nobody realized that Nobody would do it. So consequently
>> Everybody blamed Somebody when Nobody did what Anybody could have done
>> in the first place.
>>
>> This rather sounds like the Policy Group J
>>
>> Hence the need for someone, we’ll call them the Policy Officer for the
>> time being, being tasked with actually doing all this editing and
>> updating stuff that is chewed over here in the Policy Group… the
>> general tidying up, checking grammar and spelling, making the HTML go,
>> etc., is a useful background task, then when the Policy Group actually
>> decides on any change, that can then be entered in at the right place…
>> without anyone needing to worry about who was going to do it.
>>
>> Hugs from Megan
>>
>> ------------------------------------------------------------------------
>>
>> *From:*Ian G 
>> [mailto:iang AT cacert.org]
>> *Sent:* 21 February 2013 17:24
>> *To:* 
>> cacert-policy AT lists.cacert.org
>> *Subject:* Re: improving p20100306 - minor changes (TRIAL POST)
>>
>> Having discussed, read responses, and thought about it for a few days,
>> I am thinking now that the answer lies in policy.
>>
>> Because we have been challenged [0] on an issue of Policy, we should
>> get the Policy right.
>>
>> Therefore, I'm thinking in terms of copying p20100306 straight into
>> the appropriate place in PoP:
>>
>> ======================ADD at end of PoP#2:
>> *2. Basic Model*:
>> ...
>> 2.n+1 Editors may make the following changes, where
>> it is clear that the change does not change the policy:
>>
>> * fixes to errors in grammar and spelling,
>> * anchors, HTML errors, URLs & formatting,
>> * COD numbers and formatting, and
>> * other minutiae, as agreed under 2.3.
>>
>> Such changes are to be notified to the policy group, and are to be
>> folded into effect, etc, without further ado.
>>
>> ========================END OF ADDITION.
>>
>>
>>
>> With some improvement of course :) How do people feel about that?
>>
>>
>>
>>
>> iang
>>
>>
>>
>> [0] Cost-wise, it looks like we are going to spend around 2-4 weeks on
>> this regardless of how we deal with it. We have been told to spend
>> time writing down stuff we already know, we have consensus on, and is
>> established practice over many years. A.k.a. bureaucracy. Which will
>> hold up our policy work. Either way, we don't get out of the challenge
>> without *at least a vote* . Which is expensive, dammit! Which we
>> should make count... Therefore, let's turn this into an opportunity
>> and fix it in the policy. This way, we lead.
>>
>>
>> On 20/02/13 06:30 AM, Ian G wrote:
>>
>>> Software Assessment in its last telco meeting declined to take some
>>> new policy changes with links modifications, according to p20100306:
>>>
>>> Policy Officer may make the following changes,
>>> where it is clear that the change does not
>>> change the policy:
>>>
>>> URLs to track any links that move,
>>> grammatical errors,
>>> anchors, HTML errors & formatting,
>>> COD numbers and formatting
>>> other minutiae,
>>>
>>> They said that, as the Policy Officer position is not listed in the
>>> Officer's page, they decline to recognise the effect of the motion.
>>>
>>> Motion p20100306 has been very valuable because it has meant we can
>>> do things without wasting everyone's time. Policy group attention is
>>> our most valuable resource, we don't want to squander it. Following a
>>> suitable notification, it's done and complete, and policy group can
>>> concentrate more on real work.
>>>
>>> Still, the message is clear, Software Assessment have decided to stop
>>> after 3 years of success. I want to preserve the intent of the
>>> motion, and I see three possibilities:
>>>
>>> 1. vote on a policy officer.
>>>
>>> 2. adjust the above words so they say Policy Team instead
>>> of Officer, and add a caveat that the changes are
>>> notified to policy group (our general practice anyway).
>>>
>>> 3. incorporate words into PoP to that effect.
>>>
>>> What do people think? Prefer 1,2,3 or something else?
>>>
>>> I apologise in advance, but it looks like we're in for another vote
>>> on stuff we already have strong consensus on, and strong practice.
>>>
>>>
>>>
>>> iang
>>>
>> No virus found in this message.
>> Checked by AVG - www.avg.com <http://www.avg.com>
>> Version: 2013.0.2899 / Virus Database: 2639/6117 - Release Date:
> 02/19/13
>

Attachment: smime.p7s
Description: Signature cryptographique S/MIME