<div dir="ltr">Big +1 to the categories <div><br></div><div>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. </div><div><br></div><div>Refactoring the MUSTS and SHOULDS give us a strong lead on that language. </div><div>MUST == has to be satisfied</div><div>SHOULD = area for improvement - (proper use of warn, which wont fail charm proof for a change)</div><div><br></div><div>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. </div><div><br></div><div>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. </div><div><br></div><div><br></div><div><br><div class="gmail_quote"><div dir="ltr">On Fri, Mar 18, 2016 at 11:59 AM Jorge O. Castro <<a href="mailto:jorge@ubuntu.com">jorge@ubuntu.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello everyone,<br>
<br>
With 2.0 around the corner we decided to spend some time cleaning up<br>
the page everyone loves to hate, the Juju Charm Store policy:<br>
<br>
<a href="https://jujucharms.com/docs/1.25/authors-charm-policy" rel="noreferrer" target="_blank">https://jujucharms.com/docs/1.25/authors-charm-policy</a><br>
<br>
and here is what I would like to propose:<br>
<br>
<a href="https://github.com/castrojo/docs/blob/master/src/en/authors-charm-policy.md" rel="noreferrer" target="_blank">https://github.com/castrojo/docs/blob/master/src/en/authors-charm-policy.md</a><br>
<br>
I've done a few things here:<br>
<br>
- I've separated it from one huge paragraph to sections, General,<br>
Testing and Quality requirements, Metadata requirements, and Security<br>
requirements.<br>
- I've split out things that a charm/bundle MUST do and what it SHOULD<br>
do in each section to make it clearer on what is a hard requirement<br>
and what is a recommendation.<br>
- I've removed most of the Ubuntu-specific jargon and generalized it<br>
to include other OSes such as CentOS.<br>
- Made documenting interfaces and external dependencies a requirement.<br>
<br>
There are also some new policies that we need ack from ~charmers in<br>
order to implement. Specifically we've made the testing and quality<br>
requirements explicit. I've also added a requirement of using Juju<br>
Resources (which appears to be undocumented?) for payloads.<br>
<br>
Recommendations from everyone on what we should include here would be<br>
most welcome, specifically our recommendations around Windows charms<br>
is non-existent.<br>
<br>
<br>
--<br>
Jorge Castro<br>
Canonical Ltd.<br>
<a href="http://jujucharms.com/" rel="noreferrer" target="_blank">http://jujucharms.com/</a> - The fastest way to model your service<br>
<br>
--<br>
Juju mailing list<br>
<a href="mailto:Juju@lists.ubuntu.com" target="_blank">Juju@lists.ubuntu.com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/juju" rel="noreferrer" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju</a><br>
</blockquote></div></div></div>