incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niall Pemberton <niall.pember...@gmail.com>
Subject Re: Notes on branding
Date Sat, 02 Jul 2016 01:38:38 GMT
On Fri, Jul 1, 2016 at 8:47 PM, John D. Ament <johndament@apache.org> wrote:

> On Fri, Jul 1, 2016 at 3:19 PM Greg Chase <greg@gregchase.com> wrote:
>
> > On Fri, Jul 1, 2016 at 12:05 PM, Marvin Humphrey <marvin@rectangular.com
> >
> > wrote:
> >
> > > On Fri, Jul 1, 2016 at 9:35 AM, Greg Chase <greg@gregchase.com> wrote:
> > >
> > > > The branding guidelines do not address feedback such as "logo in
> > footer"
> > > or
> > > > "disclaimer is buried deep or below the fold".
> > >
> > > What would be best is if podlings just understood that intent, and as
> and
> > > took
> > > it upon themselves to ensure that their incubating status was
> > communicated
> > > effectively -- in websites, in release announcements, etc.
> > >
> >
> > Except podlings are now being told they are "not being effective enough"
> > according to an unspecified standard.
> >
>
> I can't even begin to tell you how much of this I agree with.  While I can
> sympathize with the IPMC members who feel this way, at the end of the day
> its on the incubator as a whole to explain the expectations.  This is true
> of both long standing members who have been here, to new members, to even
> members who have left and come back.  It needs to be communicated.  I see
> no mention of this on podling reports, no voices being raised.  I have
> reported on one report thus far that we need clarification from VP TM, but
> no response was received, regarding some changes to PNS's.
>

Just to come to Geode's defense here - branding was discussed when the
community put up their website a year ago and two IPMC members (me & Roman)
thought the current site was sufficient to satisfy incubator branding[1] -
so we (the IPMC) also need to understand the policy better and provide
better guidance to podlings.

Niall

[1] http://markmail.org/message/ro7rzmrhcsrpkk2m

>
> >
> > >
> > > It should be apparent to anyone who groks that intent that websites
> where
> > > the
> > > disclaimers and logos are buried subvert the branding guidelines.
> > >
> >
> > You are dealing with new community members. It should not be assumed that
> > something is grokable, especially when it seems there isn't a
> communicated
> > consensus.
> >
>
> Agreed 100%.  We don't make sure mentors are aware of these issues.
> Mentors therefor cannot provide it at a lower level to podlings.
>
>
> >
> >
> > > It seems that we will have to spell things out more aggressively.  The
> > new
> > > language should make it plain that podlings are expected to uphold the
> > > *spirit* of the guidelines, and not treat them as some bs technicality
> to
> > > work
> > > around.
> > >
> >
> > Spirits can be hard to grasp.  As I suggested before.  If being
> > prescriptive is too difficult, then force new podlings into a
> standardized
> > web template that meets requirements, and spirt.  This would actually
> > really simplify the getting started process for new podlings.  Then they
> > can either do something new with their website once they become a TLP, or
> > perhaps at some mid-level of maturity.
> >
> >
> This is where I begin to disagree.  We don't want podlings to just use
> cookie cutter websites, at least I don't believe we do.  I know I just want
> to see podlings use our guidelines as a bare minimum set of requirements
> for all of their branding.  This includes websites, docs, and releases.
> The point of the disclaimer is that there may be licensing issues within
> the release contents and as a result may not be 100% Apache License
> compliant.
>
>
> >
> > >
> > > If podlings don't like the disclaimers, they can hurry up and do the
> work
> > > to
> > > graduate.
> >
> >
> > There are no objections to the disclaimer from Geode.  The only issue is
> > the lack of guidelines and being held to an ungrokable standard.  We
> > discussed the issue in our community and the response is "So what do we
> > need to do?"
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message