No icon = no promulgation?

[Richard Harding]

On Wed, 13 Aug 2014, José Antonio Rey wrote:

> Hello,
>
> As I am subscribed to all bugs in Juju (as some of you may also be),
> today I got an email from a CakePHP charm review. On this one, a charmer
> had to reject the submission because, when promulgating, the tool runs
> `charm proof` to make sure things are not broken, not promulgating if
> any Error or Warning pops up. And there was a problem: this charm did
> not have an icon (which throws a Warning in `charm proof`, making it
> impossible to promulgate it.

Yes, charm checks are broken down into a couple of classes.

Warnings are things that allow a personal charm to be uploaded and served
to other users, but are required to be updated for promulgation.

Errors, are obvious things that we think are issues for charms regardless
of a personal branch or not. If a user uploads a charm with a proof error
it will never be ingested and put forth to users.

> I totally understand what has been done. Now, a charm cannot be
> promulgated when there are Errors or Warnings. But since not having an
> icon is a Warning, it will not allow a charmer to promulgate any charms
> which do not contain an icon, may it be because the author is asking for
> official permission (like in this case), because the service has no
> icon, or any other reasons. In some of the cases, it may be a
> fully-working charm, with no other issues apart from not having an icon.
> We even have lots of charms with no icon in the store. And about
> proposing a temporary icon, when I proposed an icon which was just an
> orange background with the service name, it got rejected. So, I don't
> know what may be an idea for a 'temporary' or 'provisional' icon.

We supply a starter file for an icon. The policy/proof is that the file is
there and is an svg image of the right sizes. I think that there are a
number of ways around this by helping the author use our default icon or
even one of our category icons that might fit in place in order to meet the
requirement for now.

> I believe having an icon is not that of a priority, and that we should
> focus in having charms that provide working services. Still, we should
> try to ensure and promote the idea of charms having icons, but I do not
> see it as a fatal error like to prevent promulgation.

Sorry, I hate to disagree here. We're building tools like the Juju GUI in
order to help users have a nice experience browsing charms. Every other
store, from Firefox/Chrome extensions to Apple/Android app stores require
an icon and sometimes even more to submit material. Promulgated material is
meant to go through curation to make sure we filter material to those that
provide the best experience and represent Juju. I think an icon is part of
that, not functionally I admit, but visually in the GUI environment and
browsing experience.

> In this case, I would be for demoting the level of the warning issued by
> `charm proof` from Warning to Information. This, as it is not something
> critical, and charms/services will still work, even with no icon. It
> doesn't affect functionality, but it only removes the pretty part (that
> can be added later) of the GUI. By doing this, we will throw something
> when `charm proof` is ran, but still allow promulgation if there is no icon.
>
> What do you guys think about it?

I'd suggest to work with the author to use either the default charm icon or
a category icon and move the charm forward. I also think it'd be good to
work with the author and perhaps provide some additional help in getting
permission for a real icon. In checking the license, it's a CC license, but
is no derivatives. Perhaps our community folks can help the author
demonstrate that permitting a derivative in the case of the charm is only
good for CakePHP users.

Please let me know if you disagree or want to setup a chat in person. I
understand the frustration of the icon, but I feel it's very important in
getting our best foot forward to users of Juju out there.

--

Rick Harding

Juju UI Engineering
https://launchpad.net/~rharding
@mitechie