Re: Notes on branding

[Gunnar Tapper]

Thanks Ted.

FYI, "Apache Trafodion" is part of the logo. I'm not putting the project
through another round of voting on that one. :)

It strikes me that the left (or right) part of a project's web site menu
could contain "Apache Incubator Project" as a standard. Such an approach
wouldn't impede website design much while making the status of the project
very clear.

Honestly, I don't want to spend a lot more time of the website itself given
that the technology is quite limited. (The project wanted a Maven-based
website so I did what I could.) It would have been another matter if I
could have use Wordpress with a good theme or something like that. :)

Gunnar

On Fri, Jul 1, 2016 at 9:16 PM, Ted Dunning  wrote:

> Gunnar,
>
> Think that page looks pretty good (not referring to the standards, just
> looking at the page).
>
> Having the word incubator near the logo might be slightly nicer, but that
> isn't such a big deal since you have that on the project name just above
> the logo and you have the Incubator logo in the banner as well.
>
> You guys nailed the spirit part of the policy.
>
> As a design note, you have the project name in the upper left hand corner
> twice. You might be able to merge those (preserving the "Incubating", of
> course) to save some real estate and make your image case more forcefully.
>
>
>
> On Fri, Jul 1, 2016 at 3:44 PM, Gunnar Tapper 
> 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
> > - Added the incubator logo on the top of the page
> > - Placed the disclaimer on the bottom of the 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.
> >
> > I hope this helps with the discussion.
> >
> > Thanks,
> >
> > Gunnar
> >
> > On Fri, Jul 1, 2016 at 1:31 PM, Mike Jumper 
> > wrote:
> >
> > > On Fri, Jul 1, 2016 at 12:05 PM, Marvin Humphrey <
> mar...@rectangular.com
> > >
> > > wrote:
> > >
> > > > On Fri, Jul 1, 2016 at 9:35 AM, Greg Chase 
> 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.*
> >
>



-- 
Thanks,

Gunnar
*If you think you can you can, if you think you can't you're right.*

Re: [DISCUSS] Incubator Logo & Branding

[Niclas Hedhman]

Suggestion; If such new Incubator logo is to be incorporated on podling
sites, could it also be standardized to have a "hover popup" containing the
standard text and possibly links to further information (both
Incubator-specific as well as podling-specific)?

Cheers
Niclas

On Sat, Jul 2, 2016 at 10:58 AM, Roman Shaposhnik 
wrote:

> On Fri, Jul 1, 2016 at 7:42 PM, John D. Ament 
> wrote:
> > On Fri, Jul 1, 2016 at 10:23 PM Roman Shaposhnik 
> > wrote:
> >
> >> On Fri, Jul 1, 2016 at 7:06 PM, John D. Ament 
> >> wrote:
> >> > All,
> >> >
> >> > As a follow up to the current discussions happening, I wanted to get
> >> > opinions from the IPMC on whether or not the Incubator logo should be
> >> > included in podling websites.
> >> >
> >> > Take https://wiki.apache.org/incubator/BrandingAuditJune2016 as a
> >> summary
> >> > of podling status.
> >> >
> >> > 29 podlings presently show the Incubator Logo.  1 podling uses a
> custom
> >> > version of the logo.  This means we're just above 50% matching.  The
> >> > branding guide indicates that this is a should, which essentially
> means
> >> > that unless there's some strong reason to not include, it is to be
> >> included
> >> > on the website.
> >> >
> >> > I believe the usage of the Incubator logo comes from including parent
> >> > project logos on sub-project websites, where podlings are essentially
> >> > sub-projects, but I can't find anything confirming this.
> >> >
> >> > If we are to require the logo to be present, we must spell out the
> URL to
> >> > the logo to use.  This may be a variety of logos, include transparency
> >> > effects, with and without borders, but we should guide projects on
> where
> >> to
> >> > find them.
> >>
> >> In general, this is a good idea, but before we all just +1 the heck
> >> out of it, lets
> >> make sure that the intent doesn't penalize the podlings by creating an
> ugly
> >> visual layout for their websites.
> >>
> >
> > Agreed, the discussion will be worthless if its just a series of +1's.
> We
> > can vote when something's been figured out as working.  I suspect that
> will
> > be a rewrite of http://incubator.apache.org/guides/branding.html#logos
>
> Correct.
>
> >> In my view, the best way to think about overall visual layout is along
> the
> >> lines
> >> suggested by Niall in a very much related discussion on Geode:
> >>http://markmail.org/message/e4p5owz5swmcyb7d
> >>
> >> To quote:
> >> ==
> >> Going back to the incubator branding issue, I think Geode should
> >> incorporate the
> >> Incubator logo in its banner at the top of the page, with the aim of
> >> replacing it with
> >> one of the Apache feather logos when it graduates to a TLP.
> >> ==
> >>
> >> I think this is a brilliant way to solve it, but it will require us to
> >> do a bit of graphic design
> >> to dovetail the Incubator artwork into the ASF style. The current logo
> >> clearly doesn't
> >> cut it, but something along the lines of:
> >> http://incubator.apache.org/images/apache-incubator.png
> >> actually might.
> >>
> >
> > Well, i'm not sure that we're the ones to do the graphic design.  We may
> > want to say that one of the incubator logos needs to be incorporated into
> > your design.  You may want to consider that this logo will be replaced by
> > the ASF feather logo once you graduate to a TLP.
> >
> > I also recall pinging Sally a long while ago about a new incubator logo
> > based on the new feather design.
>
> At this point, I honestly think that we may want to go back and make
> it a priority.
>
> Given the number of podlings in the incubator it is clear to me that
> the incubator
> visual identity should be treated on-par with ASF's visual identity.
> Yes, we're that
> important. We didn't scribble the new ASF's visual identity on a
> napkin -- we actually
> hired professionals. I think we have a pretty strong case for the IPMC
> of the same.
>
> Thanks,
> Roman.
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>


-- 
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java

Re: Notes on branding

[Ted Dunning]

Gunnar,

Think that page looks pretty good (not referring to the standards, just
looking at the page).

Having the word incubator near the logo might be slightly nicer, but that
isn't such a big deal since you have that on the project name just above
the logo and you have the Incubator logo in the banner as well.

You guys nailed the spirit part of the policy.

As a design note, you have the project name in the upper left hand corner
twice. You might be able to merge those (preserving the "Incubating", of
course) to save some real estate and make your image case more forcefully.



On Fri, Jul 1, 2016 at 3:44 PM, Gunnar Tapper 
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
> - Added the incubator logo on the top of the page
> - Placed the disclaimer on the bottom of the 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.
>
> I hope this helps with the discussion.
>
> Thanks,
>
> Gunnar
>
> On Fri, Jul 1, 2016 at 1:31 PM, Mike Jumper 
> wrote:
>
> > On Fri, Jul 1, 2016 at 12:05 PM, Marvin Humphrey  >
> > wrote:
> >
> > > On Fri, Jul 1, 2016 at 9:35 AM, Greg Chase  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.*
>

Re: [DISCUSS] Incubator Logo & Branding

[Roman Shaposhnik]

On Fri, Jul 1, 2016 at 7:42 PM, John D. Ament  wrote:
> On Fri, Jul 1, 2016 at 10:23 PM Roman Shaposhnik 
> wrote:
>
>> On Fri, Jul 1, 2016 at 7:06 PM, John D. Ament 
>> wrote:
>> > All,
>> >
>> > As a follow up to the current discussions happening, I wanted to get
>> > opinions from the IPMC on whether or not the Incubator logo should be
>> > included in podling websites.
>> >
>> > Take https://wiki.apache.org/incubator/BrandingAuditJune2016 as a
>> summary
>> > of podling status.
>> >
>> > 29 podlings presently show the Incubator Logo.  1 podling uses a custom
>> > version of the logo.  This means we're just above 50% matching.  The
>> > branding guide indicates that this is a should, which essentially means
>> > that unless there's some strong reason to not include, it is to be
>> included
>> > on the website.
>> >
>> > I believe the usage of the Incubator logo comes from including parent
>> > project logos on sub-project websites, where podlings are essentially
>> > sub-projects, but I can't find anything confirming this.
>> >
>> > If we are to require the logo to be present, we must spell out the URL to
>> > the logo to use.  This may be a variety of logos, include transparency
>> > effects, with and without borders, but we should guide projects on where
>> to
>> > find them.
>>
>> In general, this is a good idea, but before we all just +1 the heck
>> out of it, lets
>> make sure that the intent doesn't penalize the podlings by creating an ugly
>> visual layout for their websites.
>>
>
> Agreed, the discussion will be worthless if its just a series of +1's.  We
> can vote when something's been figured out as working.  I suspect that will
> be a rewrite of http://incubator.apache.org/guides/branding.html#logos

Correct.

>> In my view, the best way to think about overall visual layout is along the
>> lines
>> suggested by Niall in a very much related discussion on Geode:
>>http://markmail.org/message/e4p5owz5swmcyb7d
>>
>> To quote:
>> ==
>> Going back to the incubator branding issue, I think Geode should
>> incorporate the
>> Incubator logo in its banner at the top of the page, with the aim of
>> replacing it with
>> one of the Apache feather logos when it graduates to a TLP.
>> ==
>>
>> I think this is a brilliant way to solve it, but it will require us to
>> do a bit of graphic design
>> to dovetail the Incubator artwork into the ASF style. The current logo
>> clearly doesn't
>> cut it, but something along the lines of:
>> http://incubator.apache.org/images/apache-incubator.png
>> actually might.
>>
>
> Well, i'm not sure that we're the ones to do the graphic design.  We may
> want to say that one of the incubator logos needs to be incorporated into
> your design.  You may want to consider that this logo will be replaced by
> the ASF feather logo once you graduate to a TLP.
>
> I also recall pinging Sally a long while ago about a new incubator logo
> based on the new feather design.

At this point, I honestly think that we may want to go back and make
it a priority.

Given the number of podlings in the incubator it is clear to me that
the incubator
visual identity should be treated on-par with ASF's visual identity.
Yes, we're that
important. We didn't scribble the new ASF's visual identity on a
napkin -- we actually
hired professionals. I think we have a pretty strong case for the IPMC
of the same.

Thanks,
Roman.

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] Incubator Logo & Branding

[Roman Shaposhnik]

On Fri, Jul 1, 2016 at 7:39 PM, Ted Dunning  wrote:
> Sounds just right to me.
>
> I just spend a few minutes going through incubator sites. The number of
> sites that had the incubator logo was definitely less in my cursory
> examination than the number that made it clear that they were incubating,
> but the number of sites that didn't make it incubation status clear was
> still very high.
>
> This seems like a thing that could be cured by gentle coercion.  Mentors
> would be a first rank for that.

Gentle coercion gets to be much easier when the solutions that you're being
coerced into doesn't make once cringe. Hence my question on investing in
graphics design.

Thanks,
Roman.

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: IPMC release vote checklist

[Roman Shaposhnik]

On Fri, Jul 1, 2016 at 7:38 PM, Marvin Humphrey  wrote:
> On Fri, Jul 1, 2016 at 3:13 PM, Roman Shaposhnik  wrote:
>> On Fri, Jul 1, 2016 at 3:07 PM, Joe Witt  wrote:
>>> Is this what you're looking for
>>>
>>>http://incubator.apache.org/guides/releasemanagement.html#check-list
>>
>> That's the MPV check list ;-) but I thought we had a much more expanded one
>> on a wiki some place. It is totally possible, thought, that I'm
>> confusing it with
>> a release checklist of one of the TLPs I've seen. Hence the question.
>
> That list is the right one.  It is short because anything that wasn't
> blocking or wasn't actually policy was ruthlessly purged while the
> list was being assembled.
>
> If you look at the bottom of that link, you'll see a list to the wiki
> page with items that didn't make the cut.

Aha! I knew it existed -- I wasn't hallucinating! Thanks for the pointer.

Thanks,
Roman.

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] Incubator Logo & Branding

[John D. Ament]

On Fri, Jul 1, 2016 at 10:23 PM Roman Shaposhnik 
wrote:

> On Fri, Jul 1, 2016 at 7:06 PM, John D. Ament 
> wrote:
> > All,
> >
> > As a follow up to the current discussions happening, I wanted to get
> > opinions from the IPMC on whether or not the Incubator logo should be
> > included in podling websites.
> >
> > Take https://wiki.apache.org/incubator/BrandingAuditJune2016 as a
> summary
> > of podling status.
> >
> > 29 podlings presently show the Incubator Logo.  1 podling uses a custom
> > version of the logo.  This means we're just above 50% matching.  The
> > branding guide indicates that this is a should, which essentially means
> > that unless there's some strong reason to not include, it is to be
> included
> > on the website.
> >
> > I believe the usage of the Incubator logo comes from including parent
> > project logos on sub-project websites, where podlings are essentially
> > sub-projects, but I can't find anything confirming this.
> >
> > If we are to require the logo to be present, we must spell out the URL to
> > the logo to use.  This may be a variety of logos, include transparency
> > effects, with and without borders, but we should guide projects on where
> to
> > find them.
>
> In general, this is a good idea, but before we all just +1 the heck
> out of it, lets
> make sure that the intent doesn't penalize the podlings by creating an ugly
> visual layout for their websites.
>

Agreed, the discussion will be worthless if its just a series of +1's.  We
can vote when something's been figured out as working.  I suspect that will
be a rewrite of http://incubator.apache.org/guides/branding.html#logos



>
> In my view, the best way to think about overall visual layout is along the
> lines
> suggested by Niall in a very much related discussion on Geode:
>http://markmail.org/message/e4p5owz5swmcyb7d
>
> To quote:
> ==
> Going back to the incubator branding issue, I think Geode should
> incorporate the
> Incubator logo in its banner at the top of the page, with the aim of
> replacing it with
> one of the Apache feather logos when it graduates to a TLP.
> ==
>
> I think this is a brilliant way to solve it, but it will require us to
> do a bit of graphic design
> to dovetail the Incubator artwork into the ASF style. The current logo
> clearly doesn't
> cut it, but something along the lines of:
> http://incubator.apache.org/images/apache-incubator.png
> actually might.
>

Well, i'm not sure that we're the ones to do the graphic design.  We may
want to say that one of the incubator logos needs to be incorporated into
your design.  You may want to consider that this logo will be replaced by
the ASF feather logo once you graduate to a TLP.

I also recall pinging Sally a long while ago about a new incubator logo
based on the new feather design.

John



>
> Thanks,
> Roman.
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [DISCUSS] Incubator Logo & Branding

[Ted Dunning]

Sounds just right to me.

I just spend a few minutes going through incubator sites. The number of
sites that had the incubator logo was definitely less in my cursory
examination than the number that made it clear that they were incubating,
but the number of sites that didn't make it incubation status clear was
still very high.

This seems like a thing that could be cured by gentle coercion.  Mentors
would be a first rank for that.





On Fri, Jul 1, 2016 at 7:32 PM, Marvin Humphrey 
wrote:

> On Fri, Jul 1, 2016 at 7:06 PM, John D. Ament 
> wrote:
>
> > As a follow up to the current discussions happening, I wanted to get
> > opinions from the IPMC on whether or not the Incubator logo should be
> > included in podling websites.
>
> Here's how I would summarize the spirit of the policy:
>
> 1. It should be apparent to a typical consumer that a podling is
> "incubating".
> 2. It should be reasonably easy to figure out what "incubating" means.
>
> It's my hope that any guidelines we adopt can uphold the spirit without
> getting lost in overly specific details.
>
> I do think that including that including the Incubator logo is helpful.
> However, when the logo is buried at the bottom of a long page, it does not
> contribute very much.
>
> Marvin Humphrey
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: IPMC release vote checklist

[Marvin Humphrey]

On Fri, Jul 1, 2016 at 3:13 PM, Roman Shaposhnik  wrote:
> On Fri, Jul 1, 2016 at 3:07 PM, Joe Witt  wrote:
>> Is this what you're looking for
>>
>>http://incubator.apache.org/guides/releasemanagement.html#check-list
>
> That's the MPV check list ;-) but I thought we had a much more expanded one
> on a wiki some place. It is totally possible, thought, that I'm
> confusing it with
> a release checklist of one of the TLPs I've seen. Hence the question.

That list is the right one.  It is short because anything that wasn't
blocking or wasn't actually policy was ruthlessly purged while the
list was being assembled.

If you look at the bottom of that link, you'll see a list to the wiki
page with items that didn't make the cut.

Marvin Humphrey

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] Incubator Logo & Branding

[Marvin Humphrey]

On Fri, Jul 1, 2016 at 7:06 PM, John D. Ament  wrote:

> As a follow up to the current discussions happening, I wanted to get
> opinions from the IPMC on whether or not the Incubator logo should be
> included in podling websites.

Here's how I would summarize the spirit of the policy:

1. It should be apparent to a typical consumer that a podling is "incubating".
2. It should be reasonably easy to figure out what "incubating" means.

It's my hope that any guidelines we adopt can uphold the spirit without
getting lost in overly specific details.

I do think that including that including the Incubator logo is helpful.
However, when the logo is buried at the bottom of a long page, it does not
contribute very much.

Marvin Humphrey

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] Incubator Logo & Branding

[Roman Shaposhnik]

On Fri, Jul 1, 2016 at 7:06 PM, John D. Ament  wrote:
> All,
>
> As a follow up to the current discussions happening, I wanted to get
> opinions from the IPMC on whether or not the Incubator logo should be
> included in podling websites.
>
> Take https://wiki.apache.org/incubator/BrandingAuditJune2016 as a summary
> of podling status.
>
> 29 podlings presently show the Incubator Logo.  1 podling uses a custom
> version of the logo.  This means we're just above 50% matching.  The
> branding guide indicates that this is a should, which essentially means
> that unless there's some strong reason to not include, it is to be included
> on the website.
>
> I believe the usage of the Incubator logo comes from including parent
> project logos on sub-project websites, where podlings are essentially
> sub-projects, but I can't find anything confirming this.
>
> If we are to require the logo to be present, we must spell out the URL to
> the logo to use.  This may be a variety of logos, include transparency
> effects, with and without borders, but we should guide projects on where to
> find them.

In general, this is a good idea, but before we all just +1 the heck
out of it, lets
make sure that the intent doesn't penalize the podlings by creating an ugly
visual layout for their websites.

In my view, the best way to think about overall visual layout is along the lines
suggested by Niall in a very much related discussion on Geode:
   http://markmail.org/message/e4p5owz5swmcyb7d

To quote:
==
Going back to the incubator branding issue, I think Geode should incorporate the
Incubator logo in its banner at the top of the page, with the aim of
replacing it with
one of the Apache feather logos when it graduates to a TLP.
==

I think this is a brilliant way to solve it, but it will require us to
do a bit of graphic design
to dovetail the Incubator artwork into the ASF style. The current logo
clearly doesn't
cut it, but something along the lines of:
http://incubator.apache.org/images/apache-incubator.png
actually might.

Thanks,
Roman.

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: IPMC release vote checklist

[Justin Mclean]

Hi,

Perhaps this is what you are looking for?

http://incubator.apache.org/guides/release.html

Justin

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] Incubator Logo & Branding

[Justin Mclean]

Hi,

> As a follow up to the current discussions happening, I wanted to get
> opinions from the IPMC on whether or not the Incubator logo should be
> included in podling websites.

+1 It gives a clear indication that the project is under incubation at the ASF.

Bonus points for it linking to somewhere like http://incubator.apache.org.

Thanks,
Justin
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Notes on branding

[Roman Shaposhnik]

On Fri, Jul 1, 2016 at 6:54 PM, Tim Williams  wrote:
> On Fri, Jul 1, 2016 at 9:43 PM, John D. Ament  wrote:
>> Mike,
>>
>>
>> On Fri, Jul 1, 2016 at 9:12 PM Mike Jumper  wrote:
>>
>>> On Fri, Jul 1, 2016 at 3:44 PM, Gunnar Tapper 
>>> 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
>>> > - Added the incubator logo on the top of the page
>>> > - Placed the disclaimer on the bottom of the 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.
>>> >
>>> > I hope this helps with the discussion.
>>> >
>>> > Thanks,
>>> >
>>> > Gunnar
>>> >
>>> > On Fri, Jul 1, 2016 at 1:31 PM, Mike Jumper 
>>> > wrote:
>>> >
>>> > > On Fri, Jul 1, 2016 at 12:05 PM, Marvin Humphrey <
>>> mar...@rectangular.com
>>> > >
>>> > > wrote:
>>> > >
>>> > > > On Fri, Jul 1, 2016 at 9:35 AM, Greg Chase 
>>> 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.*
>>> >
>>>
>>> John and/or Roman, can you comment specifically on how the results of the
>>> branding audit [1] should be interpreted by the podlings concerned, and
>>> (please) provide some concrete examples of what podlings should and
>>> shouldn't do with respect to the audit?
>>>
>>
>> I would say that for now, podlings should take no action unless they are
>> contacted directly to fix something about their branding.  I jumped the gun
>> a little on contacting a few podlings that seemed to be way out, but were
>> not actually against our current branding guidelines.  According to the
>> list I put together, there are eight that are not in compliance at all with
>> the established policies.  That policy being that you must include the
>> disclaimer, and it must be worded in a specific way.
>>
>> I asked a few podlings to add the incubator logo.  This was mostly because
>> most links to the podling were not using the incubator domain.
>>
>>
>>>
>>> Where is the threshold between "Present, in footer, smaller font" and the
>>> much more colorful "Buried in footer"? Are not footers generally expected
>>> to be in a smaller font?
>>>
>>
>> Not saying that at all.  The thing I'm trying to weigh is how easily can I
>> discern whether this project 

Re: Notes on branding

[Gunnar Tapper]

On Fri, Jul 1, 2016 at 5:39 PM, John D. Ament  wrote:

> Some notes, but again only my opinion.
>
> <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.
>
> OK. I can move the text to the About section on the front page and remove
it from the footer.

>
> >
> > 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.
>
> What's the preference? The disclaimer before or after the ASL text in
documentation? Do I need to have the disclaimer on wiki pages that provide
documentation, too? For example:
https://cwiki.apache.org/confluence/display/TRAFODION/Trafodion+Contributor+Guide

If both are required, then I'd suggest that a single ASL+disclaimer
statement with guidance is provided.

Also, I'd like to point out that graduation now means that the project has
to go hunt for every place it mentions incubation to pull out the
disclaimer.

It's seems to me that the easier approach is to redirect $
project-name.apache.org to $project-name.incubator.apache.org and do
something similar for the wiki. That way, the incubation status is quite
clear.


>

>

[DISCUSS] Incubator Logo & Branding

[John D. Ament]

All,

As a follow up to the current discussions happening, I wanted to get
opinions from the IPMC on whether or not the Incubator logo should be
included in podling websites.

Take https://wiki.apache.org/incubator/BrandingAuditJune2016 as a summary
of podling status.

29 podlings presently show the Incubator Logo.  1 podling uses a custom
version of the logo.  This means we're just above 50% matching.  The
branding guide indicates that this is a should, which essentially means
that unless there's some strong reason to not include, it is to be included
on the website.

I believe the usage of the Incubator logo comes from including parent
project logos on sub-project websites, where podlings are essentially
sub-projects, but I can't find anything confirming this.

If we are to require the logo to be present, we must spell out the URL to
the logo to use.  This may be a variety of logos, include transparency
effects, with and without borders, but we should guide projects on where to
find them.

John

Re: Notes on branding

[Tim Williams]

On Fri, Jul 1, 2016 at 9:43 PM, John D. Ament  wrote:
> Mike,
>
>
> On Fri, Jul 1, 2016 at 9:12 PM Mike Jumper  wrote:
>
>> On Fri, Jul 1, 2016 at 3:44 PM, Gunnar Tapper 
>> 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
>> > - Added the incubator logo on the top of the page
>> > - Placed the disclaimer on the bottom of the 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.
>> >
>> > I hope this helps with the discussion.
>> >
>> > Thanks,
>> >
>> > Gunnar
>> >
>> > On Fri, Jul 1, 2016 at 1:31 PM, Mike Jumper 
>> > wrote:
>> >
>> > > On Fri, Jul 1, 2016 at 12:05 PM, Marvin Humphrey <
>> mar...@rectangular.com
>> > >
>> > > wrote:
>> > >
>> > > > On Fri, Jul 1, 2016 at 9:35 AM, Greg Chase 
>> 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.*
>> >
>>
>> John and/or Roman, can you comment specifically on how the results of the
>> branding audit [1] should be interpreted by the podlings concerned, and
>> (please) provide some concrete examples of what podlings should and
>> shouldn't do with respect to the audit?
>>
>
> I would say that for now, podlings should take no action unless they are
> contacted directly to fix something about their branding.  I jumped the gun
> a little on contacting a few podlings that seemed to be way out, but were
> not actually against our current branding guidelines.  According to the
> list I put together, there are eight that are not in compliance at all with
> the established policies.  That policy being that you must include the
> disclaimer, and it must be worded in a specific way.
>
> I asked a few podlings to add the incubator logo.  This was mostly because
> most links to the podling were not using the incubator domain.
>
>
>>
>> Where is the threshold between "Present, in footer, smaller font" and the
>> much more colorful "Buried in footer"? Are not footers generally expected
>> to be in a smaller font?
>>
>
> Not saying that at all.  The thing I'm trying to weigh is how easily can I
> discern whether this project is fully vetted or not.
>
> If you take Wave for example, while its at the bottom of the page, their
> entire page fits within the fold.  If you take Guacamole as another
> example, the placement makes 

Re: Notes on branding

[John D. Ament]

On Fri, Jul 1, 2016 at 9:38 PM Niall Pemberton 
wrote:

> On Fri, Jul 1, 2016 at 8:47 PM, John D. Ament 
> wrote:
>
> > On Fri, Jul 1, 2016 at 3:19 PM Greg Chase  wrote:
> >
> > > On Fri, Jul 1, 2016 at 12:05 PM, Marvin Humphrey <
> mar...@rectangular.com
> > >
> > > wrote:
> > >
> > > > On Fri, Jul 1, 2016 at 9:35 AM, Greg Chase 
> 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.
>

Geode is not out of line in its branding, as defined by the branding
guidelines today.  However, from my point of view, it is hard for me to
understand that Geode may be producing not-fully-compliant releases, due to
the disclaimer's placement and formatting.

Compare with Airflow's website: http://airflow.incubator.apache.org/

They didn't have a disclaimer 48 hours ago.

John



>
> 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?"
> > >
> >
>

Re: Notes on branding

[John D. Ament]

Mike,


On Fri, Jul 1, 2016 at 9:12 PM Mike Jumper  wrote:

> On Fri, Jul 1, 2016 at 3:44 PM, Gunnar Tapper 
> 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
> > - Added the incubator logo on the top of the page
> > - Placed the disclaimer on the bottom of the 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.
> >
> > I hope this helps with the discussion.
> >
> > Thanks,
> >
> > Gunnar
> >
> > On Fri, Jul 1, 2016 at 1:31 PM, Mike Jumper 
> > wrote:
> >
> > > On Fri, Jul 1, 2016 at 12:05 PM, Marvin Humphrey <
> mar...@rectangular.com
> > >
> > > wrote:
> > >
> > > > On Fri, Jul 1, 2016 at 9:35 AM, Greg Chase 
> 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.*
> >
>
> John and/or Roman, can you comment specifically on how the results of the
> branding audit [1] should be interpreted by the podlings concerned, and
> (please) provide some concrete examples of what podlings should and
> shouldn't do with respect to the audit?
>

I would say that for now, podlings should take no action unless they are
contacted directly to fix something about their branding.  I jumped the gun
a little on contacting a few podlings that seemed to be way out, but were
not actually against our current branding guidelines.  According to the
list I put together, there are eight that are not in compliance at all with
the established policies.  That policy being that you must include the
disclaimer, and it must be worded in a specific way.

I asked a few podlings to add the incubator logo.  This was mostly because
most links to the podling were not using the incubator domain.


>
> Where is the threshold between "Present, in footer, smaller font" and the
> much more colorful "Buried in footer"? Are not footers generally expected
> to be in a smaller font?
>

Not saying that at all.  The thing I'm trying to weigh is how easily can I
discern whether this project is fully vetted or not.

If you take Wave for example, while its at the bottom of the page, their
entire page fits within the fold.  If you take Guacamole as another
example, the placement makes it read as if it were website legal mumbo when
that's not the intent.  The disclaimer isn't a disclaimer about the podling
website.


>
> Given that it sounds like the footer is generally-accepted sensible place
> for the 

Re: Notes on branding

[Niall Pemberton]

On Fri, Jul 1, 2016 at 8:47 PM, John D. Ament  wrote:

> On Fri, Jul 1, 2016 at 3:19 PM Greg Chase  wrote:
>
> > On Fri, Jul 1, 2016 at 12:05 PM, Marvin Humphrey  >
> > wrote:
> >
> > > On Fri, Jul 1, 2016 at 9:35 AM, Greg Chase  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?"
> >
>

Re: Notes on branding

[Mike Jumper]

On Fri, Jul 1, 2016 at 3:44 PM, Gunnar Tapper 
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
> - Added the incubator logo on the top of the page
> - Placed the disclaimer on the bottom of the 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.
>
> I hope this helps with the discussion.
>
> Thanks,
>
> Gunnar
>
> On Fri, Jul 1, 2016 at 1:31 PM, Mike Jumper 
> wrote:
>
> > On Fri, Jul 1, 2016 at 12:05 PM, Marvin Humphrey  >
> > wrote:
> >
> > > On Fri, Jul 1, 2016 at 9:35 AM, Greg Chase  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.*
>

John and/or Roman, can you comment specifically on how the results of the
branding audit [1] should be interpreted by the podlings concerned, and
(please) provide some concrete examples of what podlings should and
shouldn't do with respect to the audit?

Where is the threshold between "Present, in footer, smaller font" and the
much more colorful "Buried in footer"? Are not footers generally expected
to be in a smaller font?

Given that it sounds like the footer is generally-accepted sensible place
for the disclaimer [2], and that the branding guidelines do not currently
strictly require the Incubator logo [3], I'm not sure what the audit is
trying to say at this point.

If the consensus is that the guidelines need to change, why is an audit
occurring before the actual establishment of said guidelines? If the
guidelines are not changing, why is an audit occurring which applies
undocumented criteria?

Thanks,

- Mike

[1] https://wiki.apache.org/incubator/BrandingAuditJune2016
[2]
https://lists.apache.org/thread.html/acf796a286ed8202185b2a3b3509389630f5c833982e7b857ce3ab12@%3Cgeneral.incubator.apache.org%3E
[3] http://incubator.apache.org/guides/branding.html#logos

Re: Notes on branding

[John D. Ament]

Some notes, but again only my opinion.

On Fri, Jul 1, 2016 at 6:44 PM Gunnar Tapper 
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 
> wrote:
>
> > On Fri, Jul 1, 2016 at 12:05 PM, Marvin Humphrey  >
> > wrote:
> >
> > > On Fri, Jul 1, 2016 at 9:35 AM, Greg Chase  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.*
>

Re: Notes on branding

[Gunnar Tapper]

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
- Added the incubator logo on the top of the page
- Placed the disclaimer on the bottom of the 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.

I hope this helps with the discussion.

Thanks,

Gunnar

On Fri, Jul 1, 2016 at 1:31 PM, Mike Jumper 
wrote:

> On Fri, Jul 1, 2016 at 12:05 PM, Marvin Humphrey 
> wrote:
>
> > On Fri, Jul 1, 2016 at 9:35 AM, Greg Chase  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.*

Re: IPMC release vote checklist

[John D. Ament]

On Fri, Jul 1, 2016 at 6:13 PM Roman Shaposhnik 
wrote:

> On Fri, Jul 1, 2016 at 3:07 PM, Joe Witt  wrote:
> > Is this what you're looking for
> >
> >http://incubator.apache.org/guides/releasemanagement.html#check-list
>
> That's the MPV check list ;-) but I thought we had a much more expanded one
> on a wiki some place. It is totally possible, thought, that I'm
> confusing it with
> a release checklist of one of the TLPs I've seen. Hence the question.
>

What you listed is basically the same content as what Joe pointed to.  i'm
suspecting that this is not the TLP you are looking for.


>
> Thanks,
> Roman.
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: IPMC release vote checklist

[Roman Shaposhnik]

On Fri, Jul 1, 2016 at 3:07 PM, Joe Witt  wrote:
> Is this what you're looking for
>
>http://incubator.apache.org/guides/releasemanagement.html#check-list

That's the MPV check list ;-) but I thought we had a much more expanded one
on a wiki some place. It is totally possible, thought, that I'm
confusing it with
a release checklist of one of the TLPs I've seen. Hence the question.

Thanks,
Roman.

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: IPMC release vote checklist

[Joe Witt]

Is this what you're looking for

   http://incubator.apache.org/guides/releasemanagement.html#check-list

On Fri, Jul 1, 2016 at 3:05 PM, Roman Shaposhnik  wrote:
> Hi!
>
> I remember we used to have a checklist of things published
> somewhere, but I can't find it anymore? What I'm talking about
> is something along the lines of:
>
> 
> signature and hashes good?
> DISCLAIMER is good?
> NOTICE is good?
> LICENSE is good?
> incubating in name?
> all source files have Apache headers?
> no unexpected binary files?
> can compile from source?
> can compile from source on a machine disconnected from the internet
>(provided all the dependencies are pre-installed from a published 
> manifest)?
> 
>
> Thanks,
> Roman.
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

IPMC release vote checklist

[Roman Shaposhnik]

Hi!

I remember we used to have a checklist of things published
somewhere, but I can't find it anymore? What I'm talking about
is something along the lines of:


signature and hashes good?
DISCLAIMER is good?
NOTICE is good?
LICENSE is good?
incubating in name?
all source files have Apache headers?
no unexpected binary files?
can compile from source?
can compile from source on a machine disconnected from the internet
   (provided all the dependencies are pre-installed from a published manifest)?


Thanks,
Roman.

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Notes on branding

[Gregory Chase]

On Fri, Jul 1, 2016 at 2:16 PM, John D. Ament  wrote:

> On Fri, Jul 1, 2016 at 4:52 PM Greg Chase  wrote:
>
> >
> >
> > This email encrypted by tiny buttons & fat thumbs, beta voice
> recognition,
> > and autocorrect on my iPhone.
> >
> > > On Jul 1, 2016, at 1:41 PM, John D. Ament 
> wrote:
> > >
> > >> On Fri, Jul 1, 2016 at 4:35 PM Tim Williams 
> > wrote:
> > >>
> > >> On Fri, Jul 1, 2016 at 3:05 PM, Marvin Humphrey <
> mar...@rectangular.com
> > >
> > >> wrote:
> > >>> On Fri, Jul 1, 2016 at 9:35 AM, Greg Chase 
> 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.
> > >>
> > >> I haven't heard anyone suggesting "CYA" or "buried in fine print"?
> > >> Most sites put notices at the bottom of a page similar to how we put
> > >> our equally important copyright/trademark notices at the bottom of our
> > >> home page.  That, along with having the page saying "(Incubating)" all
> > >> over the place is surely enough of a notice... this "must be above the
> > >> fold" stuff is overreaching and encroaching on the PPMC.  They have
> > >> the disclaimer, let's not overcome our boredom by being helicopter
> > >> parents...
> > >
> > > Please don't interpret the current research being done as saying that
> the
> > > logo/disclaimer has to be above the fold.  There are certain ways I've
> > seen
> > > the disclaimer where its not clear how its used, or what it's related
> to.
> > > I've seen podlings use differing fonts to make it seem unimportant, and
> > > actually think it makes more sense in the footer.
> > >
> > > John
> > >
> > >
> > The observations are listed as "issues" and this is described as a
> > "branding audit", not a "survey."
> >
> > The meaning is clear. It's fine if you choose to redefine as a result of
> > feedback.
> >
>
> Good point.  In my mind I was treating them as findings/observations.
> Reworded the title.
>
> John
>
>
> >
> >
> >
> >
> > >>
> > >> --tim
> > >>
> > >> -
> > >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > >> For additional commands, e-mail: general-h...@incubator.apache.org
> > >>
> > >>
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
> >
>


Now that is good fodder for a discussion.

Re: Advice for incubator releases and naming

[Kathy Saunders]

On Thu, Jun 30, 2016 at 1:07 AM, Bertrand Delacretaz  wrote:

>
> It's ok for a podling to change its name at any time during the
> incubation process, but the earlier the better IMO, by far. If you
> don't get a timely answer to PODLINGNAMESEARCH-105 I suggest starting
> a vote here for renaming the podling, to make the rename a decision of
> this PMC.
>
> -Bertrand
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>
Thanks for your reply.  I think we can wait for the suitable name search to
complete their work.  I believe it is better to get the rename decision
done as soon as is reasonable, but also that whatever checks need to be
made do happen.

I mostly posted this question for my understanding.  I wasn't sure how the
name change related to a release.  I did see some notes in one of the older
suitable name search entries in Jira that talked about a podling
establishing themselves and making a release before the name is approved,
but I thought it would be better in this case to have a name that is less
likely to cause confusion before making a release.  I just want to ask
advice on whether there are any dependencies on releases, etc before the
name can be approved.  Or, if there is a dependency on the name approval
before making a release.  I hope that makes sense...

Regards,
Kathy

Re: Notes on branding

[John D. Ament]

On Fri, Jul 1, 2016 at 4:52 PM Greg Chase  wrote:

>
>
> This email encrypted by tiny buttons & fat thumbs, beta voice recognition,
> and autocorrect on my iPhone.
>
> > On Jul 1, 2016, at 1:41 PM, John D. Ament  wrote:
> >
> >> On Fri, Jul 1, 2016 at 4:35 PM Tim Williams 
> wrote:
> >>
> >> On Fri, Jul 1, 2016 at 3:05 PM, Marvin Humphrey  >
> >> wrote:
> >>> On Fri, Jul 1, 2016 at 9:35 AM, Greg Chase  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.
> >>
> >> I haven't heard anyone suggesting "CYA" or "buried in fine print"?
> >> Most sites put notices at the bottom of a page similar to how we put
> >> our equally important copyright/trademark notices at the bottom of our
> >> home page.  That, along with having the page saying "(Incubating)" all
> >> over the place is surely enough of a notice... this "must be above the
> >> fold" stuff is overreaching and encroaching on the PPMC.  They have
> >> the disclaimer, let's not overcome our boredom by being helicopter
> >> parents...
> >
> > Please don't interpret the current research being done as saying that the
> > logo/disclaimer has to be above the fold.  There are certain ways I've
> seen
> > the disclaimer where its not clear how its used, or what it's related to.
> > I've seen podlings use differing fonts to make it seem unimportant, and
> > actually think it makes more sense in the footer.
> >
> > John
> >
> >
> The observations are listed as "issues" and this is described as a
> "branding audit", not a "survey."
>
> The meaning is clear. It's fine if you choose to redefine as a result of
> feedback.
>

Good point.  In my mind I was treating them as findings/observations.
Reworded the title.

John


>
>
>
>
> >>
> >> --tim
> >>
> >> -
> >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> >> For additional commands, e-mail: general-h...@incubator.apache.org
> >>
> >>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: Notes on branding

[Greg Chase]

This email encrypted by tiny buttons & fat thumbs, beta voice recognition, and 
autocorrect on my iPhone.

> On Jul 1, 2016, at 1:41 PM, John D. Ament  wrote:
> 
>> On Fri, Jul 1, 2016 at 4:35 PM Tim Williams  wrote:
>> 
>> On Fri, Jul 1, 2016 at 3:05 PM, Marvin Humphrey 
>> wrote:
>>> On Fri, Jul 1, 2016 at 9:35 AM, Greg Chase  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.
>> 
>> I haven't heard anyone suggesting "CYA" or "buried in fine print"?
>> Most sites put notices at the bottom of a page similar to how we put
>> our equally important copyright/trademark notices at the bottom of our
>> home page.  That, along with having the page saying "(Incubating)" all
>> over the place is surely enough of a notice... this "must be above the
>> fold" stuff is overreaching and encroaching on the PPMC.  They have
>> the disclaimer, let's not overcome our boredom by being helicopter
>> parents...
> 
> Please don't interpret the current research being done as saying that the
> logo/disclaimer has to be above the fold.  There are certain ways I've seen
> the disclaimer where its not clear how its used, or what it's related to.
> I've seen podlings use differing fonts to make it seem unimportant, and
> actually think it makes more sense in the footer.
> 
> John
> 
> 
The observations are listed as "issues" and this is described as a "branding 
audit", not a "survey."

The meaning is clear. It's fine if you choose to redefine as a result of 
feedback.




>> 
>> --tim
>> 
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>> 
>> 

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Notes on branding

[John D. Ament]

On Fri, Jul 1, 2016 at 4:35 PM Tim Williams  wrote:

> On Fri, Jul 1, 2016 at 3:05 PM, Marvin Humphrey 
> wrote:
> > On Fri, Jul 1, 2016 at 9:35 AM, Greg Chase  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.
>
> I haven't heard anyone suggesting "CYA" or "buried in fine print"?
> Most sites put notices at the bottom of a page similar to how we put
> our equally important copyright/trademark notices at the bottom of our
> home page.  That, along with having the page saying "(Incubating)" all
> over the place is surely enough of a notice... this "must be above the
> fold" stuff is overreaching and encroaching on the PPMC.  They have
> the disclaimer, let's not overcome our boredom by being helicopter
> parents...
>

Please don't interpret the current research being done as saying that the
logo/disclaimer has to be above the fold.  There are certain ways I've seen
the disclaimer where its not clear how its used, or what it's related to.
I've seen podlings use differing fonts to make it seem unimportant, and
actually think it makes more sense in the footer.

John


>
> --tim
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: Notes on branding

[Tim Williams]

On Fri, Jul 1, 2016 at 3:05 PM, Marvin Humphrey  wrote:
> On Fri, Jul 1, 2016 at 9:35 AM, Greg Chase  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.

I haven't heard anyone suggesting "CYA" or "buried in fine print"?
Most sites put notices at the bottom of a page similar to how we put
our equally important copyright/trademark notices at the bottom of our
home page.  That, along with having the page saying "(Incubating)" all
over the place is surely enough of a notice... this "must be above the
fold" stuff is overreaching and encroaching on the PPMC.  They have
the disclaimer, let's not overcome our boredom by being helicopter
parents...

--tim

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Notes on branding

[Mike Jumper]

On Fri, Jul 1, 2016 at 12:47 PM, John D. Ament 
wrote:

> On Fri, Jul 1, 2016 at 3:19 PM Greg Chase  wrote:
>
> ...
> >
> > 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.
>
>
There must be some middle ground between the extremes.

Cookie-cutter websites would be horrible, but there must be something
non-spiritual that podlings can reliably adhere to. If the documentation
states that podlings must do X, but they are actively frowned upon unless
they do X+1, we're heading into "pieces of flair" territory [1].

[1] https://vimeo.com/102830089

Re: Notes on branding

[John D. Ament]

On Fri, Jul 1, 2016 at 3:19 PM Greg Chase  wrote:

> On Fri, Jul 1, 2016 at 12:05 PM, Marvin Humphrey 
> wrote:
>
> > On Fri, Jul 1, 2016 at 9:35 AM, Greg Chase  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.


>
>
> >
> > 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?"
>

Re: Notes on branding

[Mike Jumper]

On Fri, Jul 1, 2016 at 12:05 PM, Marvin Humphrey 
wrote:

> On Fri, Jul 1, 2016 at 9:35 AM, Greg Chase  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?

Re: Notes on branding

[Greg Chase]

On Fri, Jul 1, 2016 at 12:05 PM, Marvin Humphrey 
wrote:

> On Fri, Jul 1, 2016 at 9:35 AM, Greg Chase  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.


>
> 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.


> 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.


>
> 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?"

Re: Notes on branding

[Marvin Humphrey]

On Fri, Jul 1, 2016 at 9:35 AM, Greg Chase  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.

It should be apparent to anyone who groks that intent that websites where the
disclaimers and logos are buried subvert the branding guidelines.

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.

If podlings don't like the disclaimers, they can hurry up and do the work to
graduate.

Marvin Humphrey

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [NOTICE] Community vote to graduate Apache Kudu

[Todd Lipcon]

On Fri, Jul 1, 2016 at 10:35 AM, Roman Shaposhnik 
wrote:

> On Fri, Jul 1, 2016 at 10:26 AM, Todd Lipcon  wrote:
> > On Fri, Jul 1, 2016 at 10:22 AM, John D. Ament 
> > wrote:
> >
> >> Is the status page accurate? Only one added committer and no releases
> while
> >> under incubation?
> >>
> >
> > Yes, just one added committer so far.
> >
> > We've had five releases during incubation (3 minor releases with new
> > features, and two bug-fix releases). You can find the links at
> > http://kudu.incubator.apache.org/releases/
> >
> > I wasn't aware that they should be listed on the status page. Where do
> they
> > go? I'll update the page.
>
> You can just put them in the news section (with dates) -- that's what
> I've seen with most
> other podlings I've evaluated.
>

OK, just added them.



>
> Also, Todd, could you please provide a breakdown of composition of the
> proposed
> PMC re: who's on it is an existing ASF member?
>
>
Sure. 6 of the proposed PMC are members:


  * Adar Dembo 
  * Binglin Chang 
  * Chris Mattman    
  * Dan Burkert 
  * David Alves 
  * Jake Farrell 
  * Jarek Jarcec Cecho  
  * Jean-Daniel Cryans 
  * Julien Le Dem   
  * Michael Stack   
  * Mike Percy 
  * Misty Stanley-Jones 
  * Todd Lipcon   


-Todd

Re: [NOTICE] Community vote to graduate Apache Kudu

[Roman Shaposhnik]

On Fri, Jul 1, 2016 at 10:26 AM, Todd Lipcon  wrote:
> On Fri, Jul 1, 2016 at 10:22 AM, John D. Ament 
> wrote:
>
>> Is the status page accurate? Only one added committer and no releases while
>> under incubation?
>>
>
> Yes, just one added committer so far.
>
> We've had five releases during incubation (3 minor releases with new
> features, and two bug-fix releases). You can find the links at
> http://kudu.incubator.apache.org/releases/
>
> I wasn't aware that they should be listed on the status page. Where do they
> go? I'll update the page.

You can just put them in the news section (with dates) -- that's what
I've seen with most
other podlings I've evaluated.

Also, Todd, could you please provide a breakdown of composition of the proposed
PMC re: who's on it is an existing ASF member?

Thanks,
Roman.

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Fwd: Requesting permission for editing Incubator PMC report

[Nabarun Nag]

Hi Nick,
The "name"  which I use for loggin in to
https://wiki.apache.org/incubator/July2016 page is Nabarun Nag.

Please do let me know if you need any other information.

Regards
Nabarun Nag


*From:* Nick Burch 
*Date:* June 30, 2016 at 4:07:03 PM PDT
*To:* general@incubator.apache.org
*Subject:* *Re: Requesting permission for editing Incubator PMC report*
*Reply-To:* general@incubator.apache.org

On Thu, 30 Jun 2016, Nabarun Nag wrote:

Please grant me the permission to append the Apache Geode podling report to
the incubator PMC page (https://wiki.apache.org/incubator/July2016).


What is your username for the incubator wiki? (Note - the wiki doesn't use
Apache ldap credentials, so you need to register if you haven't already!)

Nick

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [NOTICE] Community vote to graduate Apache Kudu

[Todd Lipcon]

On Fri, Jul 1, 2016 at 10:22 AM, John D. Ament 
wrote:

> Is the status page accurate? Only one added committer and no releases while
> under incubation?
>

Yes, just one added committer so far.

We've had five releases during incubation (3 minor releases with new
features, and two bug-fix releases). You can find the links at
http://kudu.incubator.apache.org/releases/

I wasn't aware that they should be listed on the status page. Where do they
go? I'll update the page.

-Todd

[ANNOUNCE] Apache Kudu (incubating) 0.9.1 released

[Todd Lipcon]

The Apache Kudu (incubating) team is happy to announce the release of
Kudu 0.9.1!

Kudu is an open source storage engine for structured data which
supports low-latency random access together with efficient analytical
access patterns. It is designed within the context of the Apache Hadoop
ecosystem and supports many integrations with other data analytics projects
both inside and outside of the Apache Software Foundation.

This is a bug-fix release which fixes several issues in the prior 0.9.0
release. See
http://kudu.incubator.apache.org/releases/0.9.1/docs/release_notes.html for
more information on the resolved issues.

The release can be downloaded from:
http://kudu.incubator.apache.org/releases/0.9.1/

Regards,
The Apache Kudu (incubating) team
===

Apache Kudu (incubating) is an effort undergoing incubation at The
Apache Software Foundation (ASF), sponsored by the Apache Incubator PMC.
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.

Re: [NOTICE] Community vote to graduate Apache Kudu

[John D. Ament]

Is the status page accurate? Only one added committer and no releases while
under incubation?

John

On Fri, Jul 1, 2016 at 1:19 PM Jake Farrell  wrote:

> A graduation vote has been started for Apache Kudu
>
> -Jake
>
> Graduation vote: https://s.apache.org/5hpx
> Project status page: http://incubator.apache.org/projects/kudu.html
> Graduation discussion: https://s.apache.org/T8Uj
>

[NOTICE] Community vote to graduate Apache Kudu

[Jake Farrell]

A graduation vote has been started for Apache Kudu

-Jake

Graduation vote: https://s.apache.org/5hpx
Project status page: http://incubator.apache.org/projects/kudu.html
Graduation discussion: https://s.apache.org/T8Uj

Re: Notes on branding

[John D. Ament]

On Fri, Jul 1, 2016 at 12:35 PM Greg Chase  wrote:

> Thanks for doing the audit.
>
> The Geode PPMC has noted the finding in the wiki with our site.
>
> However, we'd like to see a good example of a compliant website.
>
> The branding guidelines do not address feedback such as "logo in footer" or
> "disclaimer is buried deep or below the fold".
>

Yes, this is part of the pending work.  It seems as though there's a divide
on how prominent incubator branding needs to be.


>
> Considering the Geode web design was forked from another TLP, is it
> possible that some of the feedback is a bit arbitrary?
>

Nope.  If it came from a TLP, the TLP wouldn't need to comply with
incubator branding rules.  Specifically, TLPs are assumed to be vetted
releases that don't carry the disclaimer.


>
> Otherwise maybe all incubating projects should have the same website
> template, and then be free to evolve their design once they graduate to
> TLP.
>
> -Greg
>
> On Fri, Jul 1, 2016 at 7:37 AM, Shane Curcuru 
> wrote:
>
> > John D. Ament wrote on 6/29/16 7:36 AM:
> > > Hey guys
> > >
> > > I'm starting to go through the podlings to identify branding issues.
> > > Touched the first 12 projects, for those that had websites, 4 were not
> > > within branding requirements.
> > >
> > > I'm not sure if other scan give a hand here on contacting podlings,
> but I
> > > went through Airflow -> Fineract, and contacted Airflow, Atlas, Beam
> and
> > > Blur.  Otherwise I'll continue to churn through contacting projects.
> > >
> > > John
> > >
> >
> > Thanks for the good work!  Please do report back - here or to
> > trademarks@ - about your progress and how PPMCs respond.
> >
> > In particular, any feedback on our published policies/guidelines is very
> > important.  As we scale, we need to ensure that most podlings can figure
> > out the right thing to do from the docs, and not as much from direct
> > pushes by our volunteer mentors and IPMC folks.
> >
> > Separately, a long-term project of mine is to ensure the branding bits
> > on the incubator site are clear and point to the right parts of the
> > formal trademark policies here:
> >
> >   http://www.apache.org/foundation/marks/resources
> >
> > - Shane
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
> >
>

Re: [VOTE] Apache Kudu (incubating) 0.9.1 RC1

[Todd Lipcon]

On Tue, Jun 28, 2016 at 9:27 AM, Sergio Fernández  wrote:

>
>
> * Although redirections are correctly handled, I'd remove all getkudu.io
> links in the documentation to use the new canonical domain kudu.apache.org
>
> * I noticed you incubating releases are not clearly marked (version suffix)
> at http://kudu.apache.org/releases/ until you actually retrieve the file.
> I'd say it's something to remark, to know what releases happened before
> incubation, what during and what afterwards.
>
>
The above two are now addressed.


> * The podling status page http://incubator.apache.org/projects/kudu.html
> requires some work (I went there just to check the releases issue mentioned
> before).
>

What specific items did you note? It's up to date as far as I know, but
maybe I missed something we were supposed to edit?

-Todd

Re: Mailing list creation (DistributedLog)

[Josh Elser]

I had to hop over to Hipchat last week to poke infra about lists for Pirk.

Thankfully, Daniel made some time and knocked it out for me shortly 
after asking. Not sure if there is a reason for the delay, but a 
light-hand will probably help sort it out :)


John D. Ament wrote:

Sounds like a question better for infra.  They have been through a number
of hiccups this week.

John

On Fri, Jul 1, 2016 at 8:46 AM Flavio Junqueira  wrote:


Hi there,

I'm wondering how long it typically takes infra to create the mailing
lists for a podling. I have requested the creation of the lists for the
DistributedLog podling, but I haven't seen any response. We typically
receive the notification via the private list, and how much longer I should
wait before creating an infra ticket.

Thanks,
-Flavio
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org






-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Notes on branding

[Julian Hyde]

On 2016-07-01 07:37 (-0700), Shane Curcuru  wrote: 
> 
> In particular, any feedback on our published policies/guidelines is very
> important.  As we scale, we need to ensure that most podlings can figure
> out the right thing to do from the docs, and not as much from direct
> pushes by our volunteer mentors and IPMC folks.

+1

As a mentor, I am trying very hard not to say to my podlings “you need to fix 
x, y and z”. Because if I do, the inevitale response, five minutes later, is 
“Done.” We’re trying to teach podlings to manage their own brand, which 
involves thinking.

The audit is useful (it keeps us mentors on our toes!) but a well-documented 
policy is more important.

Julian


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Notes on branding

[Greg Chase]

Thanks for doing the audit.

The Geode PPMC has noted the finding in the wiki with our site.

However, we'd like to see a good example of a compliant website.

The branding guidelines do not address feedback such as "logo in footer" or
"disclaimer is buried deep or below the fold".

Considering the Geode web design was forked from another TLP, is it
possible that some of the feedback is a bit arbitrary?

Otherwise maybe all incubating projects should have the same website
template, and then be free to evolve their design once they graduate to TLP.

-Greg

On Fri, Jul 1, 2016 at 7:37 AM, Shane Curcuru  wrote:

> John D. Ament wrote on 6/29/16 7:36 AM:
> > Hey guys
> >
> > I'm starting to go through the podlings to identify branding issues.
> > Touched the first 12 projects, for those that had websites, 4 were not
> > within branding requirements.
> >
> > I'm not sure if other scan give a hand here on contacting podlings, but I
> > went through Airflow -> Fineract, and contacted Airflow, Atlas, Beam and
> > Blur.  Otherwise I'll continue to churn through contacting projects.
> >
> > John
> >
>
> Thanks for the good work!  Please do report back - here or to
> trademarks@ - about your progress and how PPMCs respond.
>
> In particular, any feedback on our published policies/guidelines is very
> important.  As we scale, we need to ensure that most podlings can figure
> out the right thing to do from the docs, and not as much from direct
> pushes by our volunteer mentors and IPMC folks.
>
> Separately, a long-term project of mine is to ensure the branding bits
> on the incubator site are clear and point to the right parts of the
> formal trademark policies here:
>
>   http://www.apache.org/foundation/marks/resources
>
> - Shane
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: Notes on branding

[Shane Curcuru]

John D. Ament wrote on 6/29/16 7:36 AM:
> Hey guys
> 
> I'm starting to go through the podlings to identify branding issues.
> Touched the first 12 projects, for those that had websites, 4 were not
> within branding requirements.
> 
> I'm not sure if other scan give a hand here on contacting podlings, but I
> went through Airflow -> Fineract, and contacted Airflow, Atlas, Beam and
> Blur.  Otherwise I'll continue to churn through contacting projects.
> 
> John
> 

Thanks for the good work!  Please do report back - here or to
trademarks@ - about your progress and how PPMCs respond.

In particular, any feedback on our published policies/guidelines is very
important.  As we scale, we need to ensure that most podlings can figure
out the right thing to do from the docs, and not as much from direct
pushes by our volunteer mentors and IPMC folks.

Separately, a long-term project of mine is to ensure the branding bits
on the incubator site are clear and point to the right parts of the
formal trademark policies here:

  http://www.apache.org/foundation/marks/resources

- Shane

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Accept Traffic Control into the Apache Incubator

[Phil Sorber]

+1

On Fri, Jul 1, 2016 at 8:00 AM Jan van Doorn  wrote:

> Following the discussion thread, I would like to call a VOTE on accepting
> Traffic Control into the Apache Incubator.
>
> [] +1 Accept Traffic Control into the Apache Incubator
> [] +0 Abstain.
> [] -1 Do not accept Traffic Control into the Apache Incubator because ...
>
> This vote will be open for at least 1 week (extra long to accommodate
> holiday schedules).
>
> The proposal follows, you can also access the wiki page:
> https://wiki.apache.org/incubator/TrafficControlProposal
>
> Thanks,
> JvD
>
>
> = Traffic Control Proposal =
>
> == Abstract ==
>
> Traffic Control allows you to build a large scale content delivery network
> using
> open source.
>
> == Proposal ==
>
> The goal of this proposal is to bring the Traffic Control project into the
> Apache Software Foundation.
>
> == Background ==
>
> Initially built around Apache Traffic Server as the caching software,
> Traffic
> Control implements all functions of a modern CDN except the caching
> software:
>
>  * Traffic Router is a Java Tomcat application that routes clients to the
> closest
>  available cache on the CDN using both HTTP and DNS. By using consistent
> hashing
>  it sends requests for the same content to the same cache in a group of
> caches
>  working together in a location. It takes care of routing clients around
> hot
>  spots and problems in the CDN by using the information from Traffic
> Monitor with
>  regards to state of all the caches.
>
>  * Traffic Monitor is a Java Tomcat application that implements the CDN
> health
>  protocol. Every cache in the CDN is checked using HTTP for vital stats,
> and
>  based on these stats, caches are declared healthy or unhealthy. This
> information
>  is then used by Traffic Router to make its routing decisions.
>
>  * Traffic Ops is a Perl Mojolicious and jQuery UI application for
> management and
>  monitoring of all servers in the CDN. All server and content routing
> information
>  for the CDN is managed through Traffic Ops. It also exposes RESTful API
>  endpoints for consumption by tools and other applications.
>
>  * Traffic Stats is a Go application that is used to acquire and store
> statistics
>  about CDNs controlled by Traffic Control. Traffic Stats mines metrics from
>  Traffic Monitor’s JSON APIs and stores the data in InfluxDB, and
> visualizes them
>  using Grafana.
>
>  * Traffic Analytics is a new component we are starting to build for log
> file
>  analysis, based on Apache Kafka, Heka, and Elastic Search.
>
>
> Traffic Control was developed by Comcast Cable and released as open source
> under
> the Apache 2.0 license in April of 2015. Traffic Control is deployed at
> Comcast
> and other cable operators.
>
> The Traffic Control project was presented at ApacheCon NA 2016, see
> http://bit.ly/1UwMzmR for additional background information.
>
> == Rationale ==
>
> Even though the traffic on today's CDNs is strictly defined by open
> standards,
> and there are many open source implementations of caches available, CDNs
> are
> still proprietary. The current providers of CDN-as-a-product or
> CDN-as-a-service all have their own proprietary implementation of the
> control
> plane.  The CDN control plane of one vendor can't interoperate with the CDN
> control plane of another, creating a classic vendor-lockin for
> CDN-as-a-product
> customers. Traffic Control changes that. Emerging standards from IETF (CDNi
> working group) and the Streaming Video Alliance Open Caching working group
> need
> an open source reference implementation; Traffic Control will strive to be
> that.
>
> == Initial Goals ==
>
> Initial goals of transitioning to ASF is to grow and diversify the
> community,
> and to move to a more open and inclusive development model.
>
> == Current Status ==
>
> Traffic Control is functional and deployed at Comcast and other cable
> operators.
> In the past 12 months 10 major releases have been made.
>
> === Meritocracy ===
>
> Initial development was done at Comcast Cable. Since April 2015  it has
> been
> open source, and a handful outside contributors have been added.
>
> Our main goal during incubation is to try to create a more diverse group of
> contributors and users.
>
> === Community ===
>
> Traffic Control is being used by a number of cable companies and is being
> evaluated by a number of vendors and ISPs. Two vendors have created
> products
> based on Traffic Control and are active in the community.
>
> === Core Developers ===
>
> Most of the core developers of Traffic Control are currently at Comcast.
> The
> main goal of the incubation is to grow the developer and user group into a
> community beyond Comcast and US cable.
>
> === Alignment ===
>
> Traffic Control is closely aligned with Apache Traffic Server (ATS). The
> only
> supported cache in a Traffic Control CDN at this time is ATS.  One of our
> proposed mentors is a committers to ATS, and our proposed champion the ATS
> PMC
> 

[ANNOUNCE] Apache Taverna Command-line 3.1.0-incubating

[Stian Soiland-Reyes]

The Apache Taverna (incubating) team is pleased to announce the release of:

apache-taverna-commandline 3.1.0-incubating
apache-taverna-engine 3.1.0-incubating
apache-taverna-commonactivities 2.1.0-incubating


This is the first major release of Apache Taverna since joining the
Apache Software Foundation incubator.


This announcement is also available with additional hyperlinks at:

https://s.apache.org/taverna-commandline-3.1.0


# Taverna Command-line

Apache Taverna Command-line Tool 3.1.0-incubating enables you to run
Taverna workflows from a command prompt or shell script. Workflow
results can be saved either to a folder or to a Research Object bundle
that include detailed provenance.

The Command-line Tool can run workflows defined with Apache Taverna
Language in SCUFL2 format (.wfbundle). It can also execute many
Taverna 2 workflows (.t2flow) , depending on which activities they
require.

Download apache-taverna-commandline 3.1.0-incubating:

https://taverna.incubator.apache.org/download/commandline/


# Taverna Engine

Apache Taverna Engine 3.1.0-incubating is a Java library to execute
Taverna workflows, defined using Apache Taverna Language or Taverna
2's .t2flow format. The engine provides OSGi services for monitoring
and controlling the detailed execution of workflows.

Download apache-taverna-engine 3.1.0-incubating:

https://taverna.incubator.apache.org/download/engine/


# Taverna Common Activities

Apache Taverna Common Activities 2.1.0-incubating are Java libraries
for the Taverna Engine to invoke specific activities such as
command-line tools (local/ssh), Beanshell scripts,  REST and WSDL
services, spreadsheet import, and user interactions.

This also includes the Apache Taverna WSDL Generic library, which can
be used separately to parse and invoke WSDL SOAP services.

Download apache-taverna-commonactivities 2.1.0-incubating:

https://taverna.incubator.apache.org/download/common-activities/


# Taverna Java libraries

In addition to the above, Apache Taverna Command-line relies on these
libraries which have been released earlier:

Apache Taverna OSGi 0.2.1-incubating is a plugin system for Java
console and desktop applications using OSGi, including an online
update mechanism.

Apache Taverna Language 0.15.1-incubating is a Java API that gives
programmatic access to inspecting, modifying and converting SCUFL2
workflow definitions and Research Object Bundles.

See:
https://taverna.incubator.apache.org/download/


# Changes

The below highlights changes since Taverna Command-line 3.0a2.
Developers should note that there are as well significant changes in
the back-end since Taverna 2.5, including a new OSGi-based plugin
system and support for SCUFL2 workflow definitions.


## Improved WSDL support

This release adds improved WSDL support using Apache Woden. The code
has two parsers (wsdl 1.1 based on WSDL4j and 2.0 based on Woden) that
implement a common interface from taverna-wsdl-generic.


## Source Code Name Changes

Package names have changed to be under org.apache.taverna.* and source
code modules has been reorganized. See the Javadoc for details.


## Data bundle input/output

The command line now supports the -inputbundle option to provide
structured inputs (e.g. list of lists or lists of URLs). The input
bundle can be prepared as a ZIP file or using the Taverna Language
API.

The command line now supports the -bundle option to save the Research
Object Bundle ZIP file of the workflow run, which include inputs,
outputs, intermediate values and the executed workflow. Note that for
this release the bundle only includes provenance in JSON format.


# Removed / Retired Features

## Activity types

These activities are no longer supported directly by Apache Taverna:

- RShell
- Soaplab
- Biomart

For interested developers, the source code for the above are available
separately as part of the Taverna Plugin Bioinformatics and Taverna
Extras.


## Database storage

The command line no longer supports the -embedded or -startdb options
for database storage.

Intermediate data values are stored within a Research Object Data
Bundle, which can be saved for provenance purposes using the -bundle
option.


## Baclava format

The command line no longer supports the Baclava options -inputdoc  or
-outputdoc.


# Bug Fixes

For details of bug fixes since 3.0a2, see:

- https://s.apache.org/changelog-engine-3.1.0
- https://s.apache.org/changelog-commonactivities-2.1.0
- https://s.apache.org/changelog-commandine-3.1.0


# Installation Information

## Prerequisites

- Java 1.8 or newer (tested with OpenJDK 1.8)
- Apache Maven 3.2.5 or newer

## Installation

Version 3.1.0 is the first release of the Apache Taverna Command-line
Tool. It is only available as source code, as we think this release is
mainly useful for development and testing.

Apache Taverna is planning to include a binary distribution of the
Taverna Command-line Tool with its next release. Please contact the
dev@taverna mailing list for 

[VOTE] Accept Traffic Control into the Apache Incubator

[Jan van Doorn]

Following the discussion thread, I would like to call a VOTE on accepting 
Traffic Control into the Apache Incubator.

[] +1 Accept Traffic Control into the Apache Incubator
[] +0 Abstain.
[] -1 Do not accept Traffic Control into the Apache Incubator because ...

This vote will be open for at least 1 week (extra long to accommodate holiday 
schedules).

The proposal follows, you can also access the wiki page: 
https://wiki.apache.org/incubator/TrafficControlProposal

Thanks,
JvD


= Traffic Control Proposal =

== Abstract ==

Traffic Control allows you to build a large scale content delivery network using
open source. 

== Proposal ==

The goal of this proposal is to bring the Traffic Control project into the
Apache Software Foundation.

== Background ==

Initially built around Apache Traffic Server as the caching software, Traffic
Control implements all functions of a modern CDN except the caching software:

 * Traffic Router is a Java Tomcat application that routes clients to the 
closest
 available cache on the CDN using both HTTP and DNS. By using consistent hashing
 it sends requests for the same content to the same cache in a group of caches
 working together in a location. It takes care of routing clients around hot
 spots and problems in the CDN by using the information from Traffic Monitor 
with
 regards to state of all the caches.

 * Traffic Monitor is a Java Tomcat application that implements the CDN health
 protocol. Every cache in the CDN is checked using HTTP for vital stats, and
 based on these stats, caches are declared healthy or unhealthy. This 
information
 is then used by Traffic Router to make its routing decisions.

 * Traffic Ops is a Perl Mojolicious and jQuery UI application for management 
and
 monitoring of all servers in the CDN. All server and content routing 
information
 for the CDN is managed through Traffic Ops. It also exposes RESTful API
 endpoints for consumption by tools and other applications.

 * Traffic Stats is a Go application that is used to acquire and store 
statistics
 about CDNs controlled by Traffic Control. Traffic Stats mines metrics from 
 Traffic Monitor’s JSON APIs and stores the data in InfluxDB, and visualizes 
them 
 using Grafana.

 * Traffic Analytics is a new component we are starting to build for log file 
 analysis, based on Apache Kafka, Heka, and Elastic Search.


Traffic Control was developed by Comcast Cable and released as open source under
the Apache 2.0 license in April of 2015. Traffic Control is deployed at Comcast
and other cable operators.

The Traffic Control project was presented at ApacheCon NA 2016, see 
http://bit.ly/1UwMzmR for additional background information.

== Rationale ==

Even though the traffic on today's CDNs is strictly defined by open standards,
and there are many open source implementations of caches available, CDNs are
still proprietary. The current providers of CDN-as-a-product or
CDN-as-a-service all have their own proprietary implementation of the control
plane.  The CDN control plane of one vendor can't interoperate with the CDN
control plane of another, creating a classic vendor-lockin for CDN-as-a-product
customers. Traffic Control changes that. Emerging standards from IETF (CDNi
working group) and the Streaming Video Alliance Open Caching working group need
an open source reference implementation; Traffic Control will strive to be
that.

== Initial Goals ==

Initial goals of transitioning to ASF is to grow and diversify the community,
and to move to a more open and inclusive development model.

== Current Status ==

Traffic Control is functional and deployed at Comcast and other cable operators.
In the past 12 months 10 major releases have been made.

=== Meritocracy ===

Initial development was done at Comcast Cable. Since April 2015  it has been
open source, and a handful outside contributors have been added.

Our main goal during incubation is to try to create a more diverse group of
contributors and users.

=== Community ===

Traffic Control is being used by a number of cable companies and is being
evaluated by a number of vendors and ISPs. Two vendors have created products
based on Traffic Control and are active in the community.

=== Core Developers ===

Most of the core developers of Traffic Control are currently at Comcast. The
main goal of the incubation is to grow the developer and user group into a
community beyond Comcast and US cable.

=== Alignment ===

Traffic Control is closely aligned with Apache Traffic Server (ATS). The only
supported cache in a Traffic Control CDN at this time is ATS.  One of our
proposed mentors is a committers to ATS, and our proposed champion the ATS PMC
chair.

We don't want to become a sub-project of ATS though, because we believe we
should add other caching proxies as they are deemed to be a valuable addition to
the Traffic Control CDN.

== Known Risks ==

=== Orphaned products ===

Traffic Control is a new system that does not have wide adoption, but at least
two 

Re: Mailing list creation (DistributedLog)

[John D. Ament]

Sounds like a question better for infra.  They have been through a number
of hiccups this week.

John

On Fri, Jul 1, 2016 at 8:46 AM Flavio Junqueira  wrote:

> Hi there,
>
> I'm wondering how long it typically takes infra to create the mailing
> lists for a podling. I have requested the creation of the lists for the
> DistributedLog podling, but I haven't seen any response. We typically
> receive the notification via the private list, and how much longer I should
> wait before creating an infra ticket.
>
> Thanks,
> -Flavio
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Mailing list creation (DistributedLog)

[Flavio Junqueira]

Hi there,

I'm wondering how long it typically takes infra to create the mailing lists for 
a podling. I have requested the creation of the lists for the DistributedLog 
podling, but I haven't seen any response. We typically receive the notification 
via the private list, and how much longer I should wait before creating an 
infra ticket.

Thanks,
-Flavio
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Notes on branding

[Pierre Smits]

John,

It seems to me you just defined a (potential) solution direction.

Best regards,

Pierre

On Friday, July 1, 2016, John D. Ament  wrote:

> Its definitely an option, once we have a clear sign in place.  Just don't
> forget, clutch isn't magic.  Unless we build some smarts that can visit the
> podling page, look at the webpage and see if the incubator logo are
> present, its going to be based on a flag in podlings.xml.  I can actually
> think of a way to do it with Selenium + Sikuli instead of myself going to
> each webpage.
>
> John
>
> On Fri, Jul 1, 2016 at 4:00 AM Pierre Smits  > wrote:
>
> > Hi John, All,
> >
> > My suggestion is to improve the incubator clutch, so that the overview
> > http://incubator.apache.org/clutch.html reflects whether podlings are:
> >
> >
> >1. Compliant with ASF Branding regulations
> >2. Compliant with ASF Incubator Branding regulations.
> >
> > Best regards,
> >
> > Pierre Smits
> >
> > ORRTIZ.COM 
> > OFBiz based solutions & services
> >
> > OFBiz Extensions Marketplace
> > http://oem.ofbizci.net/oci-2/
> >
> > On Fri, Jul 1, 2016 at 5:49 AM, John D. Ament  >
> > wrote:
> >
> > > All,
> > >
> > > As a follow up to this.  I've started tracking a wiki page with the
> > results
> > > of the audit.  You can find it here:
> > > https://wiki.apache.org/incubator/BrandingAuditJune2016
> > >
> > > There's two things I want to get out of this.
> > >
> > > - Agreement on our branding.  It seems like there's some notion that
> our
> > > branding rules right now are too lenient.  Do we want to require the
> > > incubator logo? Do we want both artifacts above the fold?
> > >
> > > - Communication to the podlings.  Once all issues are identified, get
> the
> > > list of issues to all offending podlings (which I'm assuming is 90% of
> > them
> > > right now, based on the first 18).  Make sure they fix them prior to
> > (next
> > > release? board report?)
> > >
> > > John
> > >
> > > On Wed, Jun 29, 2016 at 7:36 AM Pierre Smits  >
> > > wrote:
> > >
> > > > Hi John,
> > > >
> > > > Thanks for keeping up the good work and being adamant/unwavering
> > > regarding
> > > > the branding aspects visavis the podlings.
> > > >
> > > > Best regards,
> > > >
> > > > Pierre Smits
> > > >
> > > > ORRTIZ.COM 
> > > > OFBiz based solutions & services
> > > >
> > > > OFBiz Extensions Marketplace
> > > > http://oem.ofbizci.net/oci-2/
> > > >
> > > > On Wed, Jun 29, 2016 at 1:36 PM, John D. Ament <
> johndam...@apache.org >
> > > > wrote:
> > > >
> > > > > Hey guys
> > > > >
> > > > > I'm starting to go through the podlings to identify branding
> issues.
> > > > > Touched the first 12 projects, for those that had websites, 4 were
> > not
> > > > > within branding requirements.
> > > > >
> > > > > I'm not sure if other scan give a hand here on contacting podlings,
> > > but I
> > > > > went through Airflow -> Fineract, and contacted Airflow, Atlas,
> Beam
> > > and
> > > > > Blur.  Otherwise I'll continue to churn through contacting
> projects.
> > > > >
> > > > > John
> > > > >
> > > >
> > >
> >
>


-- 
Pierre Smits

ORRTIZ.COM 
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

Re: Notes on branding

[John D. Ament]

Its definitely an option, once we have a clear sign in place.  Just don't
forget, clutch isn't magic.  Unless we build some smarts that can visit the
podling page, look at the webpage and see if the incubator logo are
present, its going to be based on a flag in podlings.xml.  I can actually
think of a way to do it with Selenium + Sikuli instead of myself going to
each webpage.

John

On Fri, Jul 1, 2016 at 4:00 AM Pierre Smits  wrote:

> Hi John, All,
>
> My suggestion is to improve the incubator clutch, so that the overview
> http://incubator.apache.org/clutch.html reflects whether podlings are:
>
>
>1. Compliant with ASF Branding regulations
>2. Compliant with ASF Incubator Branding regulations.
>
> Best regards,
>
> Pierre Smits
>
> ORRTIZ.COM 
> OFBiz based solutions & services
>
> OFBiz Extensions Marketplace
> http://oem.ofbizci.net/oci-2/
>
> On Fri, Jul 1, 2016 at 5:49 AM, John D. Ament 
> wrote:
>
> > All,
> >
> > As a follow up to this.  I've started tracking a wiki page with the
> results
> > of the audit.  You can find it here:
> > https://wiki.apache.org/incubator/BrandingAuditJune2016
> >
> > There's two things I want to get out of this.
> >
> > - Agreement on our branding.  It seems like there's some notion that our
> > branding rules right now are too lenient.  Do we want to require the
> > incubator logo? Do we want both artifacts above the fold?
> >
> > - Communication to the podlings.  Once all issues are identified, get the
> > list of issues to all offending podlings (which I'm assuming is 90% of
> them
> > right now, based on the first 18).  Make sure they fix them prior to
> (next
> > release? board report?)
> >
> > John
> >
> > On Wed, Jun 29, 2016 at 7:36 AM Pierre Smits 
> > wrote:
> >
> > > Hi John,
> > >
> > > Thanks for keeping up the good work and being adamant/unwavering
> > regarding
> > > the branding aspects visavis the podlings.
> > >
> > > Best regards,
> > >
> > > Pierre Smits
> > >
> > > ORRTIZ.COM 
> > > OFBiz based solutions & services
> > >
> > > OFBiz Extensions Marketplace
> > > http://oem.ofbizci.net/oci-2/
> > >
> > > On Wed, Jun 29, 2016 at 1:36 PM, John D. Ament 
> > > wrote:
> > >
> > > > Hey guys
> > > >
> > > > I'm starting to go through the podlings to identify branding issues.
> > > > Touched the first 12 projects, for those that had websites, 4 were
> not
> > > > within branding requirements.
> > > >
> > > > I'm not sure if other scan give a hand here on contacting podlings,
> > but I
> > > > went through Airflow -> Fineract, and contacted Airflow, Atlas, Beam
> > and
> > > > Blur.  Otherwise I'll continue to churn through contacting projects.
> > > >
> > > > John
> > > >
> > >
> >
>

Re: Notes on branding

[Pierre Smits]

Hi John, All,

My suggestion is to improve the incubator clutch, so that the overview
http://incubator.apache.org/clutch.html reflects whether podlings are:


   1. Compliant with ASF Branding regulations
   2. Compliant with ASF Incubator Branding regulations.

Best regards,

Pierre Smits

ORRTIZ.COM 
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

On Fri, Jul 1, 2016 at 5:49 AM, John D. Ament  wrote:

> All,
>
> As a follow up to this.  I've started tracking a wiki page with the results
> of the audit.  You can find it here:
> https://wiki.apache.org/incubator/BrandingAuditJune2016
>
> There's two things I want to get out of this.
>
> - Agreement on our branding.  It seems like there's some notion that our
> branding rules right now are too lenient.  Do we want to require the
> incubator logo? Do we want both artifacts above the fold?
>
> - Communication to the podlings.  Once all issues are identified, get the
> list of issues to all offending podlings (which I'm assuming is 90% of them
> right now, based on the first 18).  Make sure they fix them prior to (next
> release? board report?)
>
> John
>
> On Wed, Jun 29, 2016 at 7:36 AM Pierre Smits 
> wrote:
>
> > Hi John,
> >
> > Thanks for keeping up the good work and being adamant/unwavering
> regarding
> > the branding aspects visavis the podlings.
> >
> > Best regards,
> >
> > Pierre Smits
> >
> > ORRTIZ.COM 
> > OFBiz based solutions & services
> >
> > OFBiz Extensions Marketplace
> > http://oem.ofbizci.net/oci-2/
> >
> > On Wed, Jun 29, 2016 at 1:36 PM, John D. Ament 
> > wrote:
> >
> > > Hey guys
> > >
> > > I'm starting to go through the podlings to identify branding issues.
> > > Touched the first 12 projects, for those that had websites, 4 were not
> > > within branding requirements.
> > >
> > > I'm not sure if other scan give a hand here on contacting podlings,
> but I
> > > went through Airflow -> Fineract, and contacted Airflow, Atlas, Beam
> and
> > > Blur.  Otherwise I'll continue to churn through contacting projects.
> > >
> > > John
> > >
> >
>

Re: [VOTE] Release Apache Trafodion (incubating) release 2.0.1-incubating RC3

[Roberta Marton]

Thanks for your vote. Appreciate you taking time to review the release.

The original code included a website where the code was downloaded from but
the address was no longer valid. So I found a version with the BSD 3
license. I downloaded the files and compared them to Trafodion files. I was
concerned that they might be different and that Trafodion may have made
enough changes to deserve a separate copyright.

The files did have several differences, for example, Trafodion changed some
of the method names but the basic logic was the same. So I felt that I
could replace the license and that we didn't need a separate copyright;
that is, the files were similar enough. These files are stable.

I also updated the web site location in the code to point to the BSD 3
files.

   Roberta
On Jun 30, 2016 8:42 PM, "John D. Ament"  wrote:

> +1 on the release.
> Contents look correct.
>
> One question though, are you 100% certain that the replaced license is
> correct? Are there any other changes in the impacted files that would
> require rework, or is the file stable enough that its not the case?
>
> John
>
> On Wed, Jun 29, 2016 at 5:52 PM Roberta Marton 
> wrote:
>
> > Hello,
> >
> >
> >
> > This is a call to vote on Apache Trafodion patch release 2.0.1-incubating
> > RC3 (Release Candidate 3).
> >
> >
> >
> > Apache Trafodion is a webscale SQL-on-Hadoop solution enabling
> > transactional or
> >
> > operational workloads on Hadoop.  Trafodion builds on the scalability,
> > elasticity, and
> >
> > flexibility of Hadoop. Trafodion extends Hadoop to provide guaranteed
> >
> > transactional integrity, enabling new kinds of big data applications to
> run
> > on
> >
> > Hadoop.
> >
> >
> >
> > The changes in this patch release address licensing issues found during
> the
> >
> > Apache Trafodion release 2.0.1 RC1 (Release Candidate 1) voting cycle.
> >
> >
> >
> > Changes since 2.0.1 RC1:
> >
> >[TRAFODION-2068] Missing DISCLAIMER files for release package
> >
> >[TRAFODION-2082] BSD-4 license for swsprintf and swscanf unclear
> >
> >
> >
> > The Trafodion community has approved  this release:
> >
> >
> >
> http://mail-archives.apache.org/mod_mbox/incubator-trafodion-dev/201606.mbox/ajax/%3Cab0bbe9228d5b7b487f4b9952f17ede5%40mail.gmail.com%3E
> >
> >
> >
> > The latest tag for this candidate is "2.0.1rc3". Git repository: git://
> > git.apache.org/incubator-trafodion.git:
> >
> > *
> >
> https://git-wip-us.apache.org/repos/asf?p=incubator-trafodion.git;a=commit;h=6357cb8f76ab399b451896c75273fd6f2e02d9c4
> > <
> >
> https://git-wip-us.apache.org/repos/asf?p=incubator-trafodion.git;a=commit;h=6357cb8f76ab399b451896c75273fd6f2e02d9c4
> > >*
> >
> >
> >
> > Release artifacts are:
> >
> > *
> >
> https://dist.apache.org/repos/dist/dev/incubator/trafodion/trafodion-2.0.1-RC3
> > <
> >
> https://dist.apache.org/repos/dist/dev/incubator/trafodion/trafodion-2.0.1-RC3
> > >*
> >
> >
> >
> > Artifacts are signed with my key (A44C5A05), which is in
> > https://dist.apache.org/repos/dist/release/incubator/trafodion/KEYS
> >
> >
> >
> > Instructions:
> >
> >
> >
> > Setting up build environment:
> >
> > *
> >
> https://cwiki.apache.org/confluence/display/TRAFODION/Create+Build+Environment
> > <
> >
> https://cwiki.apache.org/confluence/display/TRAFODION/Create+Build+Environment
> > >*
> >
> >
> >
> > Building:
> >
> > https://cwiki.apache.org/confluence/display/TRAFODION/Build+Source
> >
> >
> >
> > The vote is open for at least 72 hours.
> >
> >
> >
> > [ ] +1 approve
> >
> > [ ] +0 no opinion
> >
> > [ ] -1 disapprove (and reason why)
> >
> >
> >
> >   Regards,
> >
> >   Roberta
> >
>