Re: [DISCUSS] Updating the C* website design

[Melissa Logan]

Thanks to those who provided input on the new site layout. #3 was the
winner with some additional comments, which we'll work to integrate.

In tandem with the new website design, page content has been updated and/or
created as new. Input would be greatly appreciated.

The content doc, plus next steps for the site, can be found in the Jira
ticket here: https://issues.apache.org/jira/browse/CASSANDRA-16115.

Thanks!


On Wed, Sep 30, 2020 at 12:42 PM Melissa Logan 
wrote:

> Hi folks,
>
> As there were no dissenting votes, based on lazy consensus we have moved
> forward with the project as outlined in CASSANDRA-16115:
> https://issues.apache.org/jira/browse/CASSANDRA-16115
>
> If you need a break from 4.0 debugging, would really love folks’ thoughts
> on new design concepts. Elements/colors can be mixed-and-matched. See
> designs here (you have to enter email to view, but it is not retained):
> https://projects.invisionapp.com/freehand/document/7CLfsYoVb?
>
> Please share which you prefer and any comments here:
> https://doodle.com/poll/4yc369baaug5dzw7
>
> Any questions, just let me know. Thanks in advance.
>
>
> On Fri, Aug 21, 2020 at 6:44 PM Rahul Singh 
> wrote:
>
>> Seems like even Antora uses another SSG called middleman for their
>> “marketing” home page.
>>
>> https://gitlab.com/antora/antora.org
>>
>> If the convenience of having both content and docs all in one SSG for
>> code maintenance is compatible with the aesthetic/ content / taxonomy
>> strategy need for the site visitors, we’ll find out soon enough.
>>
>>
>>
>>
>> rahul.xavier.si...@gmail.com
>>
>> http://cassandra.link
>> The Apache Cassandra Knowledge Base.
>> On Aug 21, 2020, 8:54 PM -0400, Rahul Singh , wrote:
>> > Folks,
>> >
>> > I applaud the choice of Antora for documentation but I’m not sure it is
>> the best choice for generating an appealing site.
>> >
>> > Antora’s self professed strength is in technical documentation. Do we
>> want to stick to a “documentation” / utility look for the front facing site
>> or for a blog?
>> >
>> > https://gitlab.com/antora/antora/-/issues/444
>> >
>> > I don’t want to rehash any conclusion on choosing Antora for docs or
>> whether asciidoc is the choice for writing documentation.
>> >
>> > Could we think about using something like Gatsby or similar for the
>> front facing 5-10 pages + blog ? E. G. Skywalking uses vuepress.
>> >
>> > We can use asciidoc as the common format while using Antora for the
>> docs and something else for the rest of the content (
>> https://www.gatsbyjs.com/plugins/gatsby-transformer-asciidoc/)
>> >
>> > Something like Gatsby can use both Markdown and Asciidoc and we can
>> migrate from one to the other while still using the same tooling.
>> >
>> > Just some thoughts would love feedback!
>> >
>> > rahul.xavier.si...@gmail.com
>> >
>> > http://cassandra.link
>> > The Apache Cassandra Knowledge Base.
>> > On Jul 29, 2020, 1:28 PM -0400, M Brandon Williams ,
>> wrote:
>> > >
>> > > web
>>
>

Re: [DISCUSS] Updating the C* website design

[Melissa Logan]

Hi folks,

As there were no dissenting votes, based on lazy consensus we have moved
forward with the project as outlined in CASSANDRA-16115:
https://issues.apache.org/jira/browse/CASSANDRA-16115

If you need a break from 4.0 debugging, would really love folks’ thoughts
on new design concepts. Elements/colors can be mixed-and-matched. See
designs here (you have to enter email to view, but it is not retained):
https://projects.invisionapp.com/freehand/document/7CLfsYoVb?

Please share which you prefer and any comments here:
https://doodle.com/poll/4yc369baaug5dzw7

Any questions, just let me know. Thanks in advance.


On Fri, Aug 21, 2020 at 6:44 PM Rahul Singh 
wrote:

> Seems like even Antora uses another SSG called middleman for their
> “marketing” home page.
>
> https://gitlab.com/antora/antora.org
>
> If the convenience of having both content and docs all in one SSG for code
> maintenance is compatible with the aesthetic/ content / taxonomy strategy
> need for the site visitors, we’ll find out soon enough.
>
>
>
>
> rahul.xavier.si...@gmail.com
>
> http://cassandra.link
> The Apache Cassandra Knowledge Base.
> On Aug 21, 2020, 8:54 PM -0400, Rahul Singh , wrote:
> > Folks,
> >
> > I applaud the choice of Antora for documentation but I’m not sure it is
> the best choice for generating an appealing site.
> >
> > Antora’s self professed strength is in technical documentation. Do we
> want to stick to a “documentation” / utility look for the front facing site
> or for a blog?
> >
> > https://gitlab.com/antora/antora/-/issues/444
> >
> > I don’t want to rehash any conclusion on choosing Antora for docs or
> whether asciidoc is the choice for writing documentation.
> >
> > Could we think about using something like Gatsby or similar for the
> front facing 5-10 pages + blog ? E. G. Skywalking uses vuepress.
> >
> > We can use asciidoc as the common format while using Antora for the docs
> and something else for the rest of the content (
> https://www.gatsbyjs.com/plugins/gatsby-transformer-asciidoc/)
> >
> > Something like Gatsby can use both Markdown and Asciidoc and we can
> migrate from one to the other while still using the same tooling.
> >
> > Just some thoughts would love feedback!
> >
> > rahul.xavier.si...@gmail.com
> >
> > http://cassandra.link
> > The Apache Cassandra Knowledge Base.
> > On Jul 29, 2020, 1:28 PM -0400, M Brandon Williams ,
> wrote:
> > >
> > > web
>

Re: [DISCUSS] Updating the C* website design

[Rahul Singh]

Seems like even Antora uses another SSG called middleman for their “marketing” 
home page.

https://gitlab.com/antora/antora.org

If the convenience of having both content and docs all in one SSG for code 
maintenance is compatible with the aesthetic/ content / taxonomy strategy need 
for the site visitors, we’ll find out soon enough.




rahul.xavier.si...@gmail.com

http://cassandra.link
The Apache Cassandra Knowledge Base.
On Aug 21, 2020, 8:54 PM -0400, Rahul Singh , wrote:
> Folks,
>
> I applaud the choice of Antora for documentation but I’m not sure it is the 
> best choice for generating an appealing site.
>
> Antora’s self professed strength is in technical documentation. Do we want to 
> stick to a “documentation” / utility look for the front facing site or for a 
> blog?
>
> https://gitlab.com/antora/antora/-/issues/444
>
> I don’t want to rehash any conclusion on choosing Antora for docs or whether 
> asciidoc is the choice for writing documentation.
>
> Could we think about using something like Gatsby or similar for the front 
> facing 5-10 pages + blog ? E. G. Skywalking uses vuepress.
>
> We can use asciidoc as the common format while using Antora for the docs and 
> something else for the rest of the content 
> (https://www.gatsbyjs.com/plugins/gatsby-transformer-asciidoc/)
>
> Something like Gatsby can use both Markdown and Asciidoc and we can migrate 
> from one to the other while still using the same tooling.
>
> Just some thoughts would love feedback!
>
> rahul.xavier.si...@gmail.com
>
> http://cassandra.link
> The Apache Cassandra Knowledge Base.
> On Jul 29, 2020, 1:28 PM -0400, M Brandon Williams , wrote:
> >
> > web

Re: [DISCUSS] Updating the C* website design

[Rahul Singh]

Folks,

I applaud the choice of Antora for documentation but I’m not sure it is the 
best choice for generating an appealing site.

Antora’s self professed strength is in technical documentation. Do we want to 
stick to a “documentation” / utility look for the front facing site or for a 
blog?

https://gitlab.com/antora/antora/-/issues/444

I don’t want to rehash any conclusion on choosing Antora for docs or whether 
asciidoc is the choice for writing documentation.

Could we think about using something like Gatsby or similar for the front 
facing 5-10 pages + blog ? E. G. Skywalking uses vuepress.

We can use asciidoc as the common format while using Antora for the docs and 
something else for the rest of the content 
(https://www.gatsbyjs.com/plugins/gatsby-transformer-asciidoc/)

Something like Gatsby can use both Markdown and Asciidoc and we can migrate 
from one to the other while still using the same tooling.

Just some thoughts would love feedback!

rahul.xavier.si...@gmail.com

http://cassandra.link
The Apache Cassandra Knowledge Base.
On Jul 29, 2020, 1:28 PM -0400, M Brandon Williams , wrote:
>
> web

Re: [DISCUSS] Updating the C* website design

[Lorina Poland]

Thanks for the comments, Mick.

Yes, I think you are correct in what you have to say about versioned vs
non-versioned docs for the website. It's such an obvious comment that I can
only say I must have been half-asleep when Anthony and I discussed the
topic. (Maybe he was, too!)

Since Antora is one of the static site generators known for generating
content from multiple repo sources, I think I see the way forward better,
and will go back to work on it again.

Lorina



On Fri, Aug 21, 2020 at 5:26 AM Mick Semb Wever  wrote:

> As part of the work, I think all content files should be moved to
> > cassandra/doc. This would give a clear separation of concerns;
> >  - cassandra/doc contains the material (asciidoc) that is converted to
> the
> > website content.
> >  - cassandra-website hosts the live content and contains all the UI
> > resources (html templates, css, js, images) that style the content.
>
>
>
> Document authors only need to touch one repository to make content edits.
>
>
>
> How would this work when you have one version of cassandra-website and
> multiple versions of the in-tree docs.
>
> The in-tree docs (cassandra/doc/) is tied to each C* version. Folk want to
> look up the documentation specific to the version they are using. While the
> cassandra-website docs are for everything not specific to a C* version.
>
> And there are multiple versions of the in-tree docs hosted underneath the
> cassandra-website docs, see `asf-staging` and `asf-site` branches. Putting
> this in the main repo would make clones bigger. And there's also the issue
> of Antora being under MPL and we have to be strict about not distributing
> any of its files in any of our releases.
>
> I would have suggested instead, moving as much of the non-version-specific
> content to cassandra-website…
>
> regards,
> Mick
>

Re: [DISCUSS] Updating the C* website design

[Mick Semb Wever]

As part of the work, I think all content files should be moved to
> cassandra/doc. This would give a clear separation of concerns;
>  - cassandra/doc contains the material (asciidoc) that is converted to the
> website content.
>  - cassandra-website hosts the live content and contains all the UI
> resources (html templates, css, js, images) that style the content.



Document authors only need to touch one repository to make content edits.



How would this work when you have one version of cassandra-website and
multiple versions of the in-tree docs.

The in-tree docs (cassandra/doc/) is tied to each C* version. Folk want to
look up the documentation specific to the version they are using. While the
cassandra-website docs are for everything not specific to a C* version.

And there are multiple versions of the in-tree docs hosted underneath the
cassandra-website docs, see `asf-staging` and `asf-site` branches. Putting
this in the main repo would make clones bigger. And there's also the issue
of Antora being under MPL and we have to be strict about not distributing
any of its files in any of our releases.

I would have suggested instead, moving as much of the non-version-specific
content to cassandra-website…

regards,
Mick

Re: [DISCUSS] Updating the C* website design

[Anthony Grasso]

Hi Lorina and Mick,

I've raised CASSANDRA-16066
 to capture the
effort required to carry out the work of converting the markdown to
asciidoc. As part of the work, I think all content files should be moved to
cassandra/doc. This would give a clear separation of concerns;
 - cassandra/doc contains the material (asciidoc) that is converted to the
website content.
 - cassandra-website hosts the live content and contains all the UI
resources (html templates, css, js, images) that style the content.

Document authors only need to touch one repository to make content edits.
It also means they only need to run Antora in one location to generate the
content.

The proposal is a fairly common way of publishing content with Antora and
there are a number of examples out there of how to do this. Note, there
would be no alteration to design/content/layout of the website itself. The
only things changing would be the layout of the repositories and the tools
generating the content.

I'm happy to help with the changes if we think this is a good way to go.

Regards,
Anthony

On Thu, 6 Aug 2020 at 05:33, Lorina Poland  wrote:

> The one issue I see with your suggestion about versioned/non-versioned docs
> is that the cassandra/doc repo will have asciidoc files, and currently, all
> the items in the cassandra-website repo are in markdown. There are possible
> solutions (use antora for the website, put the non-versioned docs in their
> own repo which antora can use for building, for example), but that needs
> exploration.
>
> Lorina Poland
>
>
>
>
> On Wed, Aug 5, 2020 at 12:06 PM Michael Semb Wever  wrote:
>
> >
> >
> > > See that here:
> > >
> >
> https://docs.google.com/document/d/1aeNtgyPAsKcNa0GSKvl2ywlFEj30714ry4Sb5turWeE/edit?usp=sharing
> > >
> > > This outline is not complete, just my initial scribblings. Certainly
> > > collaboration would be welcome.
> >
> >
> > This is awesome Lorina. It would also be great to see all non-versioned
> > docs moved out of the cassandra repository and into the cassandra-website
> > repository (where they become easier to update).
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> >
>

Re: [DISCUSS] Updating the C* website design

[Lorina Poland]

The one issue I see with your suggestion about versioned/non-versioned docs
is that the cassandra/doc repo will have asciidoc files, and currently, all
the items in the cassandra-website repo are in markdown. There are possible
solutions (use antora for the website, put the non-versioned docs in their
own repo which antora can use for building, for example), but that needs
exploration.

Lorina Poland




On Wed, Aug 5, 2020 at 12:06 PM Michael Semb Wever  wrote:

>
>
> > See that here:
> >
> https://docs.google.com/document/d/1aeNtgyPAsKcNa0GSKvl2ywlFEj30714ry4Sb5turWeE/edit?usp=sharing
> >
> > This outline is not complete, just my initial scribblings. Certainly
> > collaboration would be welcome.
>
>
> This is awesome Lorina. It would also be great to see all non-versioned
> docs moved out of the cassandra repository and into the cassandra-website
> repository (where they become easier to update).
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: [DISCUSS] Updating the C* website design

[Michael Semb Wever]

> See that here:
> https://docs.google.com/document/d/1aeNtgyPAsKcNa0GSKvl2ywlFEj30714ry4Sb5turWeE/edit?usp=sharing
> 
> This outline is not complete, just my initial scribblings. Certainly
> collaboration would be welcome.


This is awesome Lorina. It would also be great to see all non-versioned docs 
moved out of the cassandra repository and into the cassandra-website repository 
(where they become easier to update).

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

Re: [DISCUSS] Updating the C* website design

[Ekaterina Dimitrova]

Great idea and I think a new fresh design combined with new release gives a
great vibe.
The proposed incremental approach sounds reasonable to me.
@Lorina - is the document open for comments or should we send any here? I
will try to go through it in the next few days.

Thank you
Ekaterina


On Wed, 29 Jul 2020 at 18:23, Lorina Poland  wrote:

> Perhaps I should start another thread, but I have started to outline a more
> solution-based approach to the docs that I was considering implementing.
>
> See that here:
>
> https://docs.google.com/document/d/1aeNtgyPAsKcNa0GSKvl2ywlFEj30714ry4Sb5turWeE/edit?usp=sharing
>
> This outline is not complete, just my initial scribblings. Certainly
> collaboration would be welcome.
>
> Lorina Poland
>
>
>
>
> On Wed, Jul 29, 2020 at 2:13 PM Mick Semb Wever  wrote:
>
> > > I would offer that design is important, but content matters more -- so
> > > would suggest adding content strategy/development and information
> > > architecture to the checkpoints list. For example, an ecosystem page
> > could
> > > be highly beneficial to end users (what does C* work with?), as well
> as a
> > > use case/case studies page.
> >
> >
> > Couldn't agree more Melissa. If we can come up with a list of
> > content/pages we are currently missing, and agree on it, that's going
> > to make this process easier. The more we can define and spec, the
> > better.
> >
> >
> > > like say, https://spark.apache.org or https://ignite.apache.org/,
> >
> > For the sake of brainstorming, my favourite two apache project
> > websites are skywalking.apache.org and ignite.apache.org
> > But I don't think we should limit what's possible, I certainly am not
> > a designer.
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> >
>

Re: [DISCUSS] Updating the C* website design

[Lorina Poland]

Perhaps I should start another thread, but I have started to outline a more
solution-based approach to the docs that I was considering implementing.

See that here:
https://docs.google.com/document/d/1aeNtgyPAsKcNa0GSKvl2ywlFEj30714ry4Sb5turWeE/edit?usp=sharing

This outline is not complete, just my initial scribblings. Certainly
collaboration would be welcome.

Lorina Poland




On Wed, Jul 29, 2020 at 2:13 PM Mick Semb Wever  wrote:

> > I would offer that design is important, but content matters more -- so
> > would suggest adding content strategy/development and information
> > architecture to the checkpoints list. For example, an ecosystem page
> could
> > be highly beneficial to end users (what does C* work with?), as well as a
> > use case/case studies page.
>
>
> Couldn't agree more Melissa. If we can come up with a list of
> content/pages we are currently missing, and agree on it, that's going
> to make this process easier. The more we can define and spec, the
> better.
>
>
> > like say, https://spark.apache.org or https://ignite.apache.org/,
>
> For the sake of brainstorming, my favourite two apache project
> websites are skywalking.apache.org and ignite.apache.org
> But I don't think we should limit what's possible, I certainly am not
> a designer.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: [DISCUSS] Updating the C* website design

[Mick Semb Wever]

> I would offer that design is important, but content matters more -- so
> would suggest adding content strategy/development and information
> architecture to the checkpoints list. For example, an ecosystem page could
> be highly beneficial to end users (what does C* work with?), as well as a
> use case/case studies page.


Couldn't agree more Melissa. If we can come up with a list of
content/pages we are currently missing, and agree on it, that's going
to make this process easier. The more we can define and spec, the
better.


> like say, https://spark.apache.org or https://ignite.apache.org/,

For the sake of brainstorming, my favourite two apache project
websites are skywalking.apache.org and ignite.apache.org
But I don't think we should limit what's possible, I certainly am not
a designer.

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

Re: [DISCUSS] Updating the C* website design

[Melissa Logan]

That all makes sense, Lorina! My thought was to add a consideration for
content/IA to the checklist Mick had shared (in addition to the UI/design),
but no need if that's already being handled.


On Wed, Jul 29, 2020 at 1:28 PM Brandon Williams  wrote:

> On Wed, Jul 29, 2020 at 3:06 PM Lorina Poland  wrote:
> > UI bundle, but I'm a copier of design, not a designer. To accomplish a UI
> > that is more modern, like say, https://spark.apache.org or
>
> Interesting choice, we used to look more like that in the past:
>
> https://web.archive.org/web/20100511183402/http://cassandra.apache.org/
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: [DISCUSS] Updating the C* website design

[Brandon Williams]

On Wed, Jul 29, 2020 at 3:06 PM Lorina Poland  wrote:
> UI bundle, but I'm a copier of design, not a designer. To accomplish a UI
> that is more modern, like say, https://spark.apache.org or

Interesting choice, we used to look more like that in the past:

https://web.archive.org/web/20100511183402/http://cassandra.apache.org/

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

Re: [DISCUSS] Updating the C* website design

[Lorina Poland]

To address Melissa's comments - the main reason that this proposal is
offered right now is that the Documentation renewal involves a change to a
new static site generator, Antora (https://antora.org). Because of this
change, the UI for cassandra.apache.org/doc must be rebuilt using the
Antora UI (https://gitlab.com/antora/antora-ui-default). If we are
rebuilding the UI anyway, why not take the opportunity to update the look
and feel of the whole site?

I have pretty much reproduced the current look and feel and built an antora
UI bundle, but I'm a copier of design, not a designer. To accomplish a UI
that is more modern, like say, https://spark.apache.org or
https://ignite.apache.org/, is beyond my expertise. So, an effort to do
website UI design would be concurrent with my continued work to improve the
content of both the docs pages and the other pages on the Cassandra website.

Lorina



On Wed, Jul 29, 2020 at 11:34 AM Melissa Logan 
wrote:

> I would offer that design is important, but content matters more -- so
> would suggest adding content strategy/development and information
> architecture to the checkpoints list. For example, an ecosystem page could
> be highly beneficial to end users (what does C* work with?), as well as a
> use case/case studies page.
>
>
> On Wed, Jul 29, 2020 at 7:49 AM Mick Semb Wever  wrote:
>
> > We have funds on offer to the project to hire a contractor to update
> > the website.
> >
> > Personally I think this is a fantastic opportunity, it would be great
> > to see the website afresh in coordination with the 4.0 release.
> >
> > With no up-front defining goals or improvements specified, if we go
> > forth with the offer, how can we go about optimising such a
> > contractor's time? Achieving something we all accept and own can be
> > challenging. And I am aware this is a little at odds with how open
> > source typically operates, the closest I can think of is code bounties
> > which are usually easier to define and spec in advance. In those
> > situations the bounty hunter interfaces directly with the community.
> > In this situation, we want broader community involvement on something
> > as touching as the landing page to the project's website, while
> > optimising the contractor's time to their speciality.
> >
> > If we want to take this on, how can we go about it?
> >
> > My first suggestion to throw out there, is to tackle it incrementally
> > with a few checkpoints along the way: where we can pause and discuss
> > and bike-shed all we like without having to involve the contractor's
> > time.  It’s also worth keeping in mind the ongoing work on converting
> > the in-tree docs, its design changes and impact it will have on our
> > user base…
> >
> > Some example of checkpoints are:
> >  * Various sketches presented and a straw poll from PMC (or the
> > broader dev group) (this could also be a 99design contest)
> >  * Initial prototype of selected sketch
> >  * Near completion of new website
> >  * Sign-off of final website (weighted to those actively involved in 2-3)
> >
> > Do we want to do this?
> > Do we think it is feasible?
> > Is the above suggestion sound?
> > Do we want more/less/different checkpoints?
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> >
>

Re: [DISCUSS] Updating the C* website design

[Melissa Logan]

I would offer that design is important, but content matters more -- so
would suggest adding content strategy/development and information
architecture to the checkpoints list. For example, an ecosystem page could
be highly beneficial to end users (what does C* work with?), as well as a
use case/case studies page.


On Wed, Jul 29, 2020 at 7:49 AM Mick Semb Wever  wrote:

> We have funds on offer to the project to hire a contractor to update
> the website.
>
> Personally I think this is a fantastic opportunity, it would be great
> to see the website afresh in coordination with the 4.0 release.
>
> With no up-front defining goals or improvements specified, if we go
> forth with the offer, how can we go about optimising such a
> contractor's time? Achieving something we all accept and own can be
> challenging. And I am aware this is a little at odds with how open
> source typically operates, the closest I can think of is code bounties
> which are usually easier to define and spec in advance. In those
> situations the bounty hunter interfaces directly with the community.
> In this situation, we want broader community involvement on something
> as touching as the landing page to the project's website, while
> optimising the contractor's time to their speciality.
>
> If we want to take this on, how can we go about it?
>
> My first suggestion to throw out there, is to tackle it incrementally
> with a few checkpoints along the way: where we can pause and discuss
> and bike-shed all we like without having to involve the contractor's
> time.  It’s also worth keeping in mind the ongoing work on converting
> the in-tree docs, its design changes and impact it will have on our
> user base…
>
> Some example of checkpoints are:
>  * Various sketches presented and a straw poll from PMC (or the
> broader dev group) (this could also be a 99design contest)
>  * Initial prototype of selected sketch
>  * Near completion of new website
>  * Sign-off of final website (weighted to those actively involved in 2-3)
>
> Do we want to do this?
> Do we think it is feasible?
> Is the above suggestion sound?
> Do we want more/less/different checkpoints?
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>