Charm Store policy updates and refinement for 2.0

[Antonio Rosales]

On Fri, Mar 18, 2016 at 1:28 PM, Charles Butler
<charles.butler at canonical.com> wrote:
> Big +1 to the categories
>
> What i'd like to see is the policy document move to strong language where we
> can build tooling around the automated checking of policy.
>
> Refactoring the MUSTS and SHOULDS give us a strong lead on that language.
> MUST == has to be satisfied
> SHOULD = area for improvement - (proper use of warn, which wont fail charm
> proof for a change)
>
> eg: We require OSI approved licenses, we can scan the copyright file for
> that with a license bot to find the lingo of approved licenses, otherwise it
> flags for human review. It may be an acceptable license we're not aware of.
>
> The more points in policy we can convert to strongly typed lingo, the more
> targeted and automated we can make portions of policy review, and also
> scopes the mission of ~charmers. A limited resource who is responsible for
> enforcing this document.

Strongly agree. The more binary we make the policy the easier it is
for folks to understand what the need to accomplish to get it
recommended. Plus, it mapd lingo, the more
> targeted and automated we can make portions of policy review, and also
> scopes the mission of ~charmers. A limited resource who is responsible for
> enforcing this document. os well to review queue check list.  Thus in that vein
- Consider dropping the "Must" from the "General Guidelines" as some
point are very objective there.
- Reference Fuctional Testing in the Deployment section
- We should be explicit for the items typically called out that are
needed in readmes, ie steps to smoke test, config options to set,
relations to set, upstream links, and how to get the software

I'll propose a branch with above suggestions, but thought I should
also mail here.

-thanks,
Antonio


>
>
>
> On Fri, Mar 18, 2016 at 11:59 AM Jorge O. Castro <jorge at ubuntu.com> wrote:
>>
>> Hello everyone,
>>
>> With 2.0 around the corner we decided to spend some time cleaning up
>> the page everyone loves to hate, the Juju Charm Store policy:
>>
>> https://jujucharms.com/docs/1.25/authors-charm-policy
>>
>> and here is what I would like to propose:
>>
>>
>> https://github.com/castrojo/docs/blob/master/src/en/authors-charm-policy.md
>>
>> I've done a few things here:
>>
>> - I've separated it from one huge paragraph to sections, General,
>> Testing and Quality requirements, Metadata requirements, and Security
>> requirements.
>> - I've split out things that a charm/bundle MUST do and what it SHOULD
>> do in each section to make it clearer on what is a hard requirement
>> and what is a recommendation.
>> - I've removed most of the Ubuntu-specific jargon and generalized it
>> to include other OSes such as CentOS.
>> - Made documenting interfaces and external dependencies a requirement.
>>
>> There are also some new policies that we need ack from ~charmers in
>> order to implement. Specifically we've made the testing and quality
>> requirements explicit. I've also added a requirement of using Juju
>> Resources (which appears to be undocumented?) for payloads.
>>
>> Recommendations from everyone on what we should include here would be
>> most welcome, specifically our recommendations around Windows charms
>> is non-existent.
>>
>>
>> --
>> Jorge Castro
>> Canonical Ltd.
>> http://jujucharms.com/ - The fastest way to model your service
>>
>> --
>> Juju mailing list
>> Juju at lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju
>
>
> --
> Juju mailing list
> Juju at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>



-- 
Antonio Rosales
Ecosystem Engineering
Canonical