incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John D. Ament" <johndam...@apache.org>
Subject Re: Notes on branding
Date Fri, 01 Jul 2016 23:39:15 GMT
Some notes, but again only my opinion.

On Fri, Jul 1, 2016 at 6:44 PM Gunnar Tapper <tapper.gunnar@gmail.com>
wrote:

> Let me offer up a concrete example since I struggle with the issue of
> branding: http://trafodion.apache.org/documentation.html
>
> I chose the following approach based on input from out mentor Stack:
>
> - Added (incubator) to the menu bar
>

IMHO, this isn't necessary.  The branding guide clearly uses "Apache
Podling-Name"


> - Added the incubator logo on the top of the page
>

<3
Just to be clear, I believe the inclusion of logo is a typical ask for the
parent/sub project structure, though I can't find anything definitive on
the matter.


> - Placed the disclaimer on the bottom of the page
>

<3

My only nit pick with the disclaimer placement is that its even below your
normal footer.  The more appropriate place is the about section on the home
page.  My interpretation is that this needs to be on your website and in
your documentation.  Not on every page.


>
> I did you placeholders in the documentation for things like mailing list,
> project names, and cross-documentation links to make renaming a matter of
> updating pom.xml files and rebuilding.
>
> However, I did NOT put incubator disclaimers or even an incubator status in
> the documentation simply because it felt like over communication of
> incubator status. As you'll see, the Apache license language is included in
> PDF and web-book formats but not the incubator disclaimer. I don't know
> whether I made the right choice. If I didn't, then I'd think that the
> guidance should state that web pages and documentation should include BOTH
> the ASL text and the incubator-disclaimer text.
>

Inclusion in the documentation is required.  But see my note above.  We're
not asking you to inundate the users with it (from my POV).  I would put it
in an intro section if it were up to me.


>
> I hope this helps with the discussion.
>
> Thanks,
>
> Gunnar
>
> On Fri, Jul 1, 2016 at 1:31 PM, Mike Jumper <mike.jumper@guac-dev.org>
> 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".
> > >
> > > Incubation disclaimers are intended to be substantive.  They are not
> CYA
> > > legal
> > > boilerplate that can be are buried in fine print. The intent is to
> > > communicate
> > > (effectively!) to consumers that a project is incubating. That way,
> > people
> > > will know that certain caveats apply:
> > >
> > >     Apache Foo is an effort undergoing incubation at The Apache
> Software
> > >     Foundation (ASF), sponsored by the Apache Incubator.  Incubation is
> > >     required of all newly accepted projects until a further review
> > > indicates
> > >     that the infrastructure, communications, and decision making
> process
> > > have
> > >     stabilized in a manner consistent with other successful ASF
> projects.
> > >     While incubation status is not necessarily a reflection of the
> > >     completeness or stability of the code, it does indicate that the
> > > project
> > >     has yet to be fully endorsed by the ASF.
> > >
> > > 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.
> > >
> > >
> > Can you cite, as an example, an incubating project's website where you
> > would consider the incubating status effectively communicated, and the
> > disclaimer not buried?
> >
>
>
>
> --
> Thanks,
>
> Gunnar
> *If you think you can you can, if you think you can't you're right.*
>

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