Re: New website launch

[Laimonas Simutis]

Yeah, let me look over that PR one more time. It's quite a beast! That's
another reason to get that merged, things will just continue to pile up.
Thank you for your patience with this.

On Sun, Feb 24, 2019 at 6:06 PM Shannon Deminick  wrote:

> Wow! For some reason I didn't think it was all going to happen that
> quickly, very cool.
>
> Since the build is currently coming from my forked repository, it means the
> "Improve this doc" buttons points back to it instead of the lucene.net
> one.
> To fix this it means we'd have to merge this PR
> https://github.com/apache/lucenenet/pull/206. The good news is that the
> "Improve this doc" buttons work since I've already got a PR to fix some
> links :)
>
> The PR is pretty huge but it doesn't touch any code in the Lucene.Net
> project but it does update some .cs files to fix the csharp docs (which is
> based on the automated tool we've made
> /src/dotnet/tools/JavaDocToMarkdownConverter which is also updated in this
> PR)
>
> I'd be happy to then make 2x separate PRs for the remaining website and
> docs tasks
>
> Do you think that's doable?
>
>
>
> On Mon, Feb 25, 2019 at 1:15 AM Laimonas Simutis  wrote:
>
> > It's live!
> >
> > Now to get CI going again and prep for release!
> >
> > Laimonas
> >
> > On Sat, Feb 23, 2019, 06:40 Laimonas Simutis  wrote:
> >
> > > Jira ticket was created yesterday, waiting for infra. If you want to
> > > follow along:
> > > https://issues.apache.org/jira/projects/INFRA/issues/INFRA-17890
> > >
> > > On Fri, Feb 22, 2019 at 9:16 AM Wyatt Barnett  >
> > > wrote:
> > >
> > >> +1, great work!
> > >>
> > >> On Fri, Feb 22, 2019 at 8:55 AM Prescott Nasser <
> geobmx...@hotmail.com>
> > >> wrote:
> > >>
> > >> > +1 nice work Shannon!
> > >> > 
> > >> > From: Laimonas Simutis 
> > >> > Sent: Friday, February 22, 2019 3:54:09 AM
> > >> > To: dev@lucenenet.apache.org
> > >> > Subject: New website launch
> > >> >
> > >> > Hello,
> > >> >
> > >> > We are just about ready to merge Shannon's PR for the new website
> into
> > >> the
> > >> > new site repo. You can take a look at the PR here:
> > >> > https://github.com/apache/lucenenet-site/pull/1 and the site itself
> > >> here:
> > >> > https://lucenenetsite.azurewebsites.net
> > >> >
> > >> > Having an updated site will bring in a more modern look as well as
> > give
> > >> us
> > >> > a place where we can quickly and conveniently update current status,
> > >> > contributing, and other sections.
> > >> >
> > >> > Big shout out to Shannon for all the work, and Shad who initially
> > guided
> > >> > Shannon through the site needs.
> > >> >
> > >> > I am going to open a ticket with Apache Infra asking to update
> > >> > https://lucenenet.apache.org to be based on the git repo. Let's
> hope
> > my
> > >> > lack of PMC group status will not interfere with the request
> > >> >
> > >> > Please let us know if there are any objections. If there are things
> > >> that we
> > >> > want to adjust, we can go through a PR process and iterate since
> > >> publishing
> > >> > will be a matter of merging a branch on github.
> > >> >
> > >> >
> > >> > Laimonas
> > >> >
> > >>
> > >
> >
>

Re: New website launch

[Shannon Deminick]

Wow! For some reason I didn't think it was all going to happen that
quickly, very cool.

Since the build is currently coming from my forked repository, it means the
"Improve this doc" buttons points back to it instead of the lucene.net one.
To fix this it means we'd have to merge this PR
https://github.com/apache/lucenenet/pull/206. The good news is that the
"Improve this doc" buttons work since I've already got a PR to fix some
links :)

The PR is pretty huge but it doesn't touch any code in the Lucene.Net
project but it does update some .cs files to fix the csharp docs (which is
based on the automated tool we've made
/src/dotnet/tools/JavaDocToMarkdownConverter which is also updated in this
PR)

I'd be happy to then make 2x separate PRs for the remaining website and
docs tasks

Do you think that's doable?



On Mon, Feb 25, 2019 at 1:15 AM Laimonas Simutis  wrote:

> It's live!
>
> Now to get CI going again and prep for release!
>
> Laimonas
>
> On Sat, Feb 23, 2019, 06:40 Laimonas Simutis  wrote:
>
> > Jira ticket was created yesterday, waiting for infra. If you want to
> > follow along:
> > https://issues.apache.org/jira/projects/INFRA/issues/INFRA-17890
> >
> > On Fri, Feb 22, 2019 at 9:16 AM Wyatt Barnett 
> > wrote:
> >
> >> +1, great work!
> >>
> >> On Fri, Feb 22, 2019 at 8:55 AM Prescott Nasser 
> >> wrote:
> >>
> >> > +1 nice work Shannon!
> >> > 
> >> > From: Laimonas Simutis 
> >> > Sent: Friday, February 22, 2019 3:54:09 AM
> >> > To: dev@lucenenet.apache.org
> >> > Subject: New website launch
> >> >
> >> > Hello,
> >> >
> >> > We are just about ready to merge Shannon's PR for the new website into
> >> the
> >> > new site repo. You can take a look at the PR here:
> >> > https://github.com/apache/lucenenet-site/pull/1 and the site itself
> >> here:
> >> > https://lucenenetsite.azurewebsites.net
> >> >
> >> > Having an updated site will bring in a more modern look as well as
> give
> >> us
> >> > a place where we can quickly and conveniently update current status,
> >> > contributing, and other sections.
> >> >
> >> > Big shout out to Shannon for all the work, and Shad who initially
> guided
> >> > Shannon through the site needs.
> >> >
> >> > I am going to open a ticket with Apache Infra asking to update
> >> > https://lucenenet.apache.org to be based on the git repo. Let's hope
> my
> >> > lack of PMC group status will not interfere with the request
> >> >
> >> > Please let us know if there are any objections. If there are things
> >> that we
> >> > want to adjust, we can go through a PR process and iterate since
> >> publishing
> >> > will be a matter of merging a branch on github.
> >> >
> >> >
> >> > Laimonas
> >> >
> >>
> >
>

Re: New website launch

[Laimonas Simutis]

It's live!

Now to get CI going again and prep for release!

Laimonas

On Sat, Feb 23, 2019, 06:40 Laimonas Simutis  wrote:

> Jira ticket was created yesterday, waiting for infra. If you want to
> follow along:
> https://issues.apache.org/jira/projects/INFRA/issues/INFRA-17890
>
> On Fri, Feb 22, 2019 at 9:16 AM Wyatt Barnett 
> wrote:
>
>> +1, great work!
>>
>> On Fri, Feb 22, 2019 at 8:55 AM Prescott Nasser 
>> wrote:
>>
>> > +1 nice work Shannon!
>> > 
>> > From: Laimonas Simutis 
>> > Sent: Friday, February 22, 2019 3:54:09 AM
>> > To: dev@lucenenet.apache.org
>> > Subject: New website launch
>> >
>> > Hello,
>> >
>> > We are just about ready to merge Shannon's PR for the new website into
>> the
>> > new site repo. You can take a look at the PR here:
>> > https://github.com/apache/lucenenet-site/pull/1 and the site itself
>> here:
>> > https://lucenenetsite.azurewebsites.net
>> >
>> > Having an updated site will bring in a more modern look as well as give
>> us
>> > a place where we can quickly and conveniently update current status,
>> > contributing, and other sections.
>> >
>> > Big shout out to Shannon for all the work, and Shad who initially guided
>> > Shannon through the site needs.
>> >
>> > I am going to open a ticket with Apache Infra asking to update
>> > https://lucenenet.apache.org to be based on the git repo. Let's hope my
>> > lack of PMC group status will not interfere with the request
>> >
>> > Please let us know if there are any objections. If there are things
>> that we
>> > want to adjust, we can go through a PR process and iterate since
>> publishing
>> > will be a matter of merging a branch on github.
>> >
>> >
>> > Laimonas
>> >
>>
>

Re: New website launch

[Laimonas Simutis]

Jira ticket was created yesterday, waiting for infra. If you want to follow
along: https://issues.apache.org/jira/projects/INFRA/issues/INFRA-17890

On Fri, Feb 22, 2019 at 9:16 AM Wyatt Barnett 
wrote:

> +1, great work!
>
> On Fri, Feb 22, 2019 at 8:55 AM Prescott Nasser 
> wrote:
>
> > +1 nice work Shannon!
> > 
> > From: Laimonas Simutis 
> > Sent: Friday, February 22, 2019 3:54:09 AM
> > To: dev@lucenenet.apache.org
> > Subject: New website launch
> >
> > Hello,
> >
> > We are just about ready to merge Shannon's PR for the new website into
> the
> > new site repo. You can take a look at the PR here:
> > https://github.com/apache/lucenenet-site/pull/1 and the site itself
> here:
> > https://lucenenetsite.azurewebsites.net
> >
> > Having an updated site will bring in a more modern look as well as give
> us
> > a place where we can quickly and conveniently update current status,
> > contributing, and other sections.
> >
> > Big shout out to Shannon for all the work, and Shad who initially guided
> > Shannon through the site needs.
> >
> > I am going to open a ticket with Apache Infra asking to update
> > https://lucenenet.apache.org to be based on the git repo. Let's hope my
> > lack of PMC group status will not interfere with the request
> >
> > Please let us know if there are any objections. If there are things that
> we
> > want to adjust, we can go through a PR process and iterate since
> publishing
> > will be a matter of merging a branch on github.
> >
> >
> > Laimonas
> >
>

Re: New website launch

[Wyatt Barnett]

+1, great work!

On Fri, Feb 22, 2019 at 8:55 AM Prescott Nasser 
wrote:

> +1 nice work Shannon!
> 
> From: Laimonas Simutis 
> Sent: Friday, February 22, 2019 3:54:09 AM
> To: dev@lucenenet.apache.org
> Subject: New website launch
>
> Hello,
>
> We are just about ready to merge Shannon's PR for the new website into the
> new site repo. You can take a look at the PR here:
> https://github.com/apache/lucenenet-site/pull/1 and the site itself here:
> https://lucenenetsite.azurewebsites.net
>
> Having an updated site will bring in a more modern look as well as give us
> a place where we can quickly and conveniently update current status,
> contributing, and other sections.
>
> Big shout out to Shannon for all the work, and Shad who initially guided
> Shannon through the site needs.
>
> I am going to open a ticket with Apache Infra asking to update
> https://lucenenet.apache.org to be based on the git repo. Let's hope my
> lack of PMC group status will not interfere with the request
>
> Please let us know if there are any objections. If there are things that we
> want to adjust, we can go through a PR process and iterate since publishing
> will be a matter of merging a branch on github.
>
>
> Laimonas
>

Re: New website launch

[Prescott Nasser]

+1 nice work Shannon!

From: Laimonas Simutis 
Sent: Friday, February 22, 2019 3:54:09 AM
To: dev@lucenenet.apache.org
Subject: New website launch

Hello,

We are just about ready to merge Shannon's PR for the new website into the
new site repo. You can take a look at the PR here:
https://github.com/apache/lucenenet-site/pull/1 and the site itself here:
https://lucenenetsite.azurewebsites.net

Having an updated site will bring in a more modern look as well as give us
a place where we can quickly and conveniently update current status,
contributing, and other sections.

Big shout out to Shannon for all the work, and Shad who initially guided
Shannon through the site needs.

I am going to open a ticket with Apache Infra asking to update
https://lucenenet.apache.org to be based on the git repo. Let's hope my
lack of PMC group status will not interfere with the request

Please let us know if there are any objections. If there are things that we
want to adjust, we can go through a PR process and iterate since publishing
will be a matter of merging a branch on github.


Laimonas

RE: New website - steps to get this launched

[Prescott Nasser]

I think what we'll want to do is create a branch in our repo that is 
specifically for the website (they recommend "asf-site" as the branch. This 
assumes the new site can be compiled into static files via buildbot / Jenkins, 
if not we probably have to pre-process so that what is committed to git is what 
can go through buildbot/Jenkins or is already static.

I'm not familiar with the new site or how it's built, but if that all works, we 
should create that branch (or someone can create a PR and one of the committers 
can merge it) and then we should open a ticket with infrastructure team to 
finalize the configuration.

I can help with merging a PR, or opening the ticket with infra if someone can 
get it to that stage



-Original Message-
From: Laimonas Simutis  
Sent: Friday, January 18, 2019 6:09 AM
To: dev@lucenenet.apache.org
Subject: Re: New website - steps to get this launched

This seems to have some good info:

https://www.apache.org/dev/project-site

I should have time to review and get back with more info in case no one else 
gets to it first.

It seems that it's a matter of generating static files and placing it in the 
appropriate location in the repo so that apache servers can pick it up.

Some of the trickier bits like downloads cgi, we can point to nuget for beta 
and the old downloads.cgi page for older bits until we get that straightened 
out.

We can worry automating this as we go, let's get the site updated with manual 
generation if we have to and iterate on that.

Shannon, once I setup my lucene env and reorient with the docs and repo 
migration that just happened, I can merge your PR. I just want to make sure we 
got the git locations right after the migration.


Laimonas


On Fri, Jan 18, 2019, 06:41 Shannon Deminick  Happy to host anywhere, only thing is that we need to follow the 
> Apache rules and from what I read it needs to be done by them unless 
> anyone knows differently?
>
> On Fri., 18 Jan. 2019, 20:50 George Kinsman  wrote:
>
> > Hi, any reason a simple GitHub pages wouldn't work?
> >
> > It's a static site built with Hugo so it just outputs html at the 
> > end of the day. It would then be linkable from the GitHub repo at 
> > lucenenet.github.io. It also means that changes to the site could be 
> > automatically published via GitHub action.
> >
> > Get Outlook for Android<https://aka.ms/ghei36>
> >
> > ____
> > From: Itamar Syn-Hershko 
> > Sent: Friday, January 18, 2019 8:21:46 AM
> > To: dev@lucenenet.apache.org
> > Subject: Re: New website - steps to get this launched
> >
> > Hi, I will gladly host the website on our cloud infra until all that
> Apache
> > infra is figured out
> >
> > On Fri, Jan 18, 2019, 2:06 AM Shannon Deminick  wrote:
> >
> > > Hi all,
> > >
> > > Revisiting this new website (and docs stuff) based on the last 
> > > thread
> > >
> > >
> >
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist
> s.apache.org%2Fthread.html%2F22c097a7c6eee169dfc80dbb1fc433c026b1806f8
> 25a599dcf426ed3%40%253Cdev.lucenenet.apache.org%253E&data=02%7C01%
> 7C%7Cba9d6890dd854b430c4308d67d1e068f%7C84df9e7fe9f640afb435aa
> aa%7C1%7C0%7C636833965245921546&sdata=H0pDk8xeImJTw1C9kN5eiPPxdxB1
> %2BwmVn%2FfxpJhBEyA%3D&reserved=0
> > >
> > > Seems the consensus is to try to get this new site launched as a 
> > > start
> to
> > > try to promote a bit more development for this project.
> > >
> > > I've updated the GH PR with a task list for both the website and 
> > > docs including links, etc... :
> >
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> ub.com%2Fapache%2Flucenenet%2Fpull%2F206&data=02%7C01%7C%7Cba9d689
> 0dd854b430c4308d67d1e068f%7C84df9e7fe9f640afb435%7C1%7C0%7
> C636833965245921546&sdata=ELEQ4H0CR3R54kAMxHAd8i08Y2AvkFiigYRBx53E
> u5s%3D&reserved=0
> > >
> > > (I should prob split the PR into 2 - one for website and one for 
> > > docs,
> > but
> > > can do that later)
> > >
> > > Most of the website tasks are very easy and is just filling in 
> > > content
> > but
> > > there are some interesting ones about hosting, branding, download 
> > > CGI
> > page
> > > (whether this is a strict requirement or not)
> > >
> > > Anyone have experience with the apache project site hosting, and 
> > > specifically using *gitpubsub* (since that seems to be the 
> > > simplest way
> > to
> > > host this) and how we can make the switch from what we have 
> > > currently
> to
> > > this new site?
> > >
> > > Anyone feel like figuring out what branding policies need to be 
> > > updated/fixed with the new site?
> > >
> > > Let me know if you have other comments about that task list
> > >
> >
>

Re: New website - steps to get this launched

[Laimonas Simutis]

This seems to have some good info:

https://www.apache.org/dev/project-site

I should have time to review and get back with more info in case no one
else gets to it first.

It seems that it's a matter of generating static files and placing it in
the appropriate location in the repo so that apache servers can pick it up.

Some of the trickier bits like downloads cgi, we can point to nuget for
beta and the old downloads.cgi page for older bits until we get that
straightened out.

We can worry automating this as we go, let's get the site updated with
manual generation if we have to and iterate on that.

Shannon, once I setup my lucene env and reorient with the docs and repo
migration that just happened, I can merge your PR. I just want to make sure
we got the git locations right after the migration.


Laimonas


On Fri, Jan 18, 2019, 06:41 Shannon Deminick  Happy to host anywhere, only thing is that we need to follow the Apache
> rules and from what I read it needs to be done by them unless anyone knows
> differently?
>
> On Fri., 18 Jan. 2019, 20:50 George Kinsman  wrote:
>
> > Hi, any reason a simple GitHub pages wouldn't work?
> >
> > It's a static site built with Hugo so it just outputs html at the end of
> > the day. It would then be linkable from the GitHub repo at
> > lucenenet.github.io. It also means that changes to the site could be
> > automatically published via GitHub action.
> >
> > Get Outlook for Android<https://aka.ms/ghei36>
> >
> > 
> > From: Itamar Syn-Hershko 
> > Sent: Friday, January 18, 2019 8:21:46 AM
> > To: dev@lucenenet.apache.org
> > Subject: Re: New website - steps to get this launched
> >
> > Hi, I will gladly host the website on our cloud infra until all that
> Apache
> > infra is figured out
> >
> > On Fri, Jan 18, 2019, 2:06 AM Shannon Deminick  wrote:
> >
> > > Hi all,
> > >
> > > Revisiting this new website (and docs stuff) based on the last thread
> > >
> > >
> >
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.apache.org%2Fthread.html%2F22c097a7c6eee169dfc80dbb1fc433c026b1806f825a599dcf426ed3%40%253Cdev.lucenenet.apache.org%253E&data=02%7C01%7C%7Cba9d6890dd854b430c4308d67d1e068f%7C84df9e7fe9f640afb435%7C1%7C0%7C636833965245921546&sdata=H0pDk8xeImJTw1C9kN5eiPPxdxB1%2BwmVn%2FfxpJhBEyA%3D&reserved=0
> > >
> > > Seems the consensus is to try to get this new site launched as a start
> to
> > > try to promote a bit more development for this project.
> > >
> > > I've updated the GH PR with a task list for both the website and docs
> > > including links, etc... :
> >
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Flucenenet%2Fpull%2F206&data=02%7C01%7C%7Cba9d6890dd854b430c4308d67d1e068f%7C84df9e7fe9f640afb435%7C1%7C0%7C636833965245921546&sdata=ELEQ4H0CR3R54kAMxHAd8i08Y2AvkFiigYRBx53Eu5s%3D&reserved=0
> > >
> > > (I should prob split the PR into 2 - one for website and one for docs,
> > but
> > > can do that later)
> > >
> > > Most of the website tasks are very easy and is just filling in content
> > but
> > > there are some interesting ones about hosting, branding, download CGI
> > page
> > > (whether this is a strict requirement or not)
> > >
> > > Anyone have experience with the apache project site hosting, and
> > > specifically using *gitpubsub* (since that seems to be the simplest way
> > to
> > > host this) and how we can make the switch from what we have currently
> to
> > > this new site?
> > >
> > > Anyone feel like figuring out what branding policies need to be
> > > updated/fixed with the new site?
> > >
> > > Let me know if you have other comments about that task list
> > >
> >
>

Re: New website - steps to get this launched

[Shannon Deminick]

Happy to host anywhere, only thing is that we need to follow the Apache
rules and from what I read it needs to be done by them unless anyone knows
differently?

On Fri., 18 Jan. 2019, 20:50 George Kinsman  Hi, any reason a simple GitHub pages wouldn't work?
>
> It's a static site built with Hugo so it just outputs html at the end of
> the day. It would then be linkable from the GitHub repo at
> lucenenet.github.io. It also means that changes to the site could be
> automatically published via GitHub action.
>
> Get Outlook for Android<https://aka.ms/ghei36>
>
> 
> From: Itamar Syn-Hershko 
> Sent: Friday, January 18, 2019 8:21:46 AM
> To: dev@lucenenet.apache.org
> Subject: Re: New website - steps to get this launched
>
> Hi, I will gladly host the website on our cloud infra until all that Apache
> infra is figured out
>
> On Fri, Jan 18, 2019, 2:06 AM Shannon Deminick 
> > Hi all,
> >
> > Revisiting this new website (and docs stuff) based on the last thread
> >
> >
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.apache.org%2Fthread.html%2F22c097a7c6eee169dfc80dbb1fc433c026b1806f825a599dcf426ed3%40%253Cdev.lucenenet.apache.org%253E&data=02%7C01%7C%7Cba9d6890dd854b430c4308d67d1e068f%7C84df9e7fe9f640afb435%7C1%7C0%7C636833965245921546&sdata=H0pDk8xeImJTw1C9kN5eiPPxdxB1%2BwmVn%2FfxpJhBEyA%3D&reserved=0
> >
> > Seems the consensus is to try to get this new site launched as a start to
> > try to promote a bit more development for this project.
> >
> > I've updated the GH PR with a task list for both the website and docs
> > including links, etc... :
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Flucenenet%2Fpull%2F206&data=02%7C01%7C%7Cba9d6890dd854b430c4308d67d1e068f%7C84df9e7fe9f640afb435%7C1%7C0%7C636833965245921546&sdata=ELEQ4H0CR3R54kAMxHAd8i08Y2AvkFiigYRBx53Eu5s%3D&reserved=0
> >
> > (I should prob split the PR into 2 - one for website and one for docs,
> but
> > can do that later)
> >
> > Most of the website tasks are very easy and is just filling in content
> but
> > there are some interesting ones about hosting, branding, download CGI
> page
> > (whether this is a strict requirement or not)
> >
> > Anyone have experience with the apache project site hosting, and
> > specifically using *gitpubsub* (since that seems to be the simplest way
> to
> > host this) and how we can make the switch from what we have currently to
> > this new site?
> >
> > Anyone feel like figuring out what branding policies need to be
> > updated/fixed with the new site?
> >
> > Let me know if you have other comments about that task list
> >
>

Re: New website - steps to get this launched

[George Kinsman]

Hi, any reason a simple GitHub pages wouldn't work?

It's a static site built with Hugo so it just outputs html at the end of the 
day. It would then be linkable from the GitHub repo at lucenenet.github.io. It 
also means that changes to the site could be automatically published via GitHub 
action.

Get Outlook for Android<https://aka.ms/ghei36>


From: Itamar Syn-Hershko 
Sent: Friday, January 18, 2019 8:21:46 AM
To: dev@lucenenet.apache.org
Subject: Re: New website - steps to get this launched

Hi, I will gladly host the website on our cloud infra until all that Apache
infra is figured out

On Fri, Jan 18, 2019, 2:06 AM Shannon Deminick  Hi all,
>
> Revisiting this new website (and docs stuff) based on the last thread
>
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.apache.org%2Fthread.html%2F22c097a7c6eee169dfc80dbb1fc433c026b1806f825a599dcf426ed3%40%253Cdev.lucenenet.apache.org%253E&data=02%7C01%7C%7Cba9d6890dd854b430c4308d67d1e068f%7C84df9e7fe9f640afb435%7C1%7C0%7C636833965245921546&sdata=H0pDk8xeImJTw1C9kN5eiPPxdxB1%2BwmVn%2FfxpJhBEyA%3D&reserved=0
>
> Seems the consensus is to try to get this new site launched as a start to
> try to promote a bit more development for this project.
>
> I've updated the GH PR with a task list for both the website and docs
> including links, etc... : 
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Flucenenet%2Fpull%2F206&data=02%7C01%7C%7Cba9d6890dd854b430c4308d67d1e068f%7C84df9e7fe9f640afb435%7C1%7C0%7C636833965245921546&sdata=ELEQ4H0CR3R54kAMxHAd8i08Y2AvkFiigYRBx53Eu5s%3D&reserved=0
>
> (I should prob split the PR into 2 - one for website and one for docs, but
> can do that later)
>
> Most of the website tasks are very easy and is just filling in content but
> there are some interesting ones about hosting, branding, download CGI page
> (whether this is a strict requirement or not)
>
> Anyone have experience with the apache project site hosting, and
> specifically using *gitpubsub* (since that seems to be the simplest way to
> host this) and how we can make the switch from what we have currently to
> this new site?
>
> Anyone feel like figuring out what branding policies need to be
> updated/fixed with the new site?
>
> Let me know if you have other comments about that task list
>

Re: New website - steps to get this launched

[Itamar Syn-Hershko]

Hi, I will gladly host the website on our cloud infra until all that Apache
infra is figured out

On Fri, Jan 18, 2019, 2:06 AM Shannon Deminick  Hi all,
>
> Revisiting this new website (and docs stuff) based on the last thread
>
> https://lists.apache.org/thread.html/22c097a7c6eee169dfc80dbb1fc433c026b1806f825a599dcf426ed3@%3Cdev.lucenenet.apache.org%3E
>
> Seems the consensus is to try to get this new site launched as a start to
> try to promote a bit more development for this project.
>
> I've updated the GH PR with a task list for both the website and docs
> including links, etc... : https://github.com/apache/lucenenet/pull/206
>
> (I should prob split the PR into 2 - one for website and one for docs, but
> can do that later)
>
> Most of the website tasks are very easy and is just filling in content but
> there are some interesting ones about hosting, branding, download CGI page
> (whether this is a strict requirement or not)
>
> Anyone have experience with the apache project site hosting, and
> specifically using *gitpubsub* (since that seems to be the simplest way to
> host this) and how we can make the switch from what we have currently to
> this new site?
>
> Anyone feel like figuring out what branding policies need to be
> updated/fixed with the new site?
>
> Let me know if you have other comments about that task list
>

RE: New Website

[Shad Storhaug]

George,

I found some more content for the website. There are several books written
on Lucene, and even one on Lucene.Net. Not many open source projects can say
they have a book written about them, so I think we should tout that fact
even if the books do have bad reviews.

1. Instant Lucene.Net:
https://www.amazon.com/Instant-Lucene-NET-Michael-Heydt/dp/1782165940
2. Lucene 4 Cookbook:
https://www.amazon.com/Lucene-4-Cookbook-Edwood-Ng/dp/1782162283
3. Lucene in Action, Second Edition: Covers Apache Lucene 3.0:
https://www.amazon.com/Lucene-Action-Second-Covers-Apache/dp/1933988177
4: Building Search Applications: Lucene, Lingpipe, and Gate:
https://www.amazon.com/Building-Search-Applications-Lucene-Lingpipe/dp/06152
04252
5: Information Retrieval: Implementing and Evaluating Search Engines (MIT
Press): https://www.amazon.com/dp/0262528878
6: There are some others, even books written in German and Chinese

Options:

1. Contact the publishers directly and ask for permission to use the images
(can't see why that would be an issue for them).
2. Find an advertising plugin that can be tailored to only display relevant
books.

Are you still available to complete this? What you have done looks great. We
just need to add the remaining content and links and update the theme of
that CGI download page to match (see my previous email for a link to the old
repository with the website).

There is a little more work to do to get Benchmark and Replicator
integrated, after which I will be looking into how to get the website and
documentation into the build process. We should follow the same folder
structure as the current website and make the docs a subfolder. Ideally, the
build script will generate both websites and automatically update the
documentation link on the main website to point to the latest API version,
but there should also be a way to keep links to the API docs of every prior
release in an archive. Perhaps it can be another page or some kind of
dropdown that becomes visible when tapped/clicked. Either way, we will need
a way for the script to automatically update these links (move the current
documentation link to the archive, and add the newest version) on each
release build.


Thanks,
Shad Storhaug (NightOwl888)


-Original Message-
From: Shad Storhaug [mailto:s...@shadstorhaug.com] 
Sent: Tuesday, July 18, 2017 2:53 AM
To: George Kinsman
Cc: dev@lucenenet.apache.org
Subject: RE: New Website

George,

FYI - I found the source code for the old website:
https://svn.apache.org/repos/asf/lucene.net/site

I was trying to figure out how the download page
(http://lucenenet.apache.org/download.cgi) is setup. For example, how does
it determine what mirror to set as default?, where does it get the mirrors
to list?, etc. Looks like it is just a wrapper around
http://www.apache.org/dyn/mirrors/mirrors.cgi. To get the current mirror
list and "default" mirror we could either use the same approach with cgi or
it looks like we could do this using JavaScript:
https://stackoverflow.com/questions/8962757/executing-a-cgi-script-via-javas
cript

Hah - they also tried to do something with that green Lucene logo - but it
really turned out bad:
https://svn.apache.org/repos/asf/lucene.net/site/images/lucene_net_green_460
.GIF


Thanks,
Shad Storhaug (NightOwl888)



-Original Message-
From: Shad Storhaug [mailto:s...@shadstorhaug.com] 
Sent: Tuesday, July 18, 2017 12:05 AM
To: George Kinsman
Cc: dev@lucenenet.apache.org
Subject: RE: New Website

George,

Before I get into responses, what I am thinking would work best is melding
together the best ideas from these 4 websites we have to draw on:

1. https://simpleinjector.org/index.html
2. https://autofac.org/
3. https://lucenenet.apache.org/
4. https://lucene.apache.org/

The first 2 in terms of design and organization. The second 2 in terms of
content.

> Those links are great - do you think they should all be as visible as the
github/mail list at the top? Maybe that area should be reserved for the most
directly useful links? At a glance the might be:
- Github
- Mailing list archives 
- StackOverflow
- Nuget
- JIRA
The others could possibly go in sub-menu's at the top - That way they'd be
visible (as they're still v important) but not have so much 'air-time' so to
speak. Thoughts?  

I would consider the link to signing up for the mailing lists (since it
effectively is Apache's replacement for an issue tracker on GitHub) to trump
the mail archives, but other than that I agree this looks like a good "short
list" for the top of the site.

I was hoping you could find the right balance to organization. But as I
mentioned above, I like the way SimpleInjector organizes the data - in
particular they have the "Learn", "Use", and "Engage" links at the bottom.
Autofac also organizes their links similarly. Maybe we need to do some
re-categorizing

RE: New Website

[Shad Storhaug]

George,

I created some new logos with better colors (light blue, dark blue, red, red 
orange, yellow, gold, and white). The light blue, red, yellow and white look 
the best IMO. I made them the same dimensions as the logo you have now so you 
should be able to just drop them in to see what they look like.

I also took the time to make a vector magnifying glass so it scales all the way 
down to 16x16 (for the favicon) better.

Here's a screenshot: http://i.imgur.com/A3712x0.png

And the images are at: 
https://issues.apache.org/jira/projects/LUCENENET/issues/LUCENENET-589 
(colored-logos-464.zip)

Thanks,
Shad Storhaug (NightOwl888)


-Original Message-
From: Shad Storhaug [mailto:s...@shadstorhaug.com] 
Sent: Tuesday, July 18, 2017 2:53 AM
To: George Kinsman
Cc: dev@lucenenet.apache.org
Subject: RE: New Website

George,

FYI - I found the source code for the old website: 
https://svn.apache.org/repos/asf/lucene.net/site

I was trying to figure out how the download page 
(http://lucenenet.apache.org/download.cgi) is setup. For example, how does it 
determine what mirror to set as default?, where does it get the mirrors to 
list?, etc. Looks like it is just a wrapper around 
http://www.apache.org/dyn/mirrors/mirrors.cgi. To get the current mirror list 
and "default" mirror we could either use the same approach with cgi or it looks 
like we could do this using JavaScript: 
https://stackoverflow.com/questions/8962757/executing-a-cgi-script-via-javascript

Hah - they also tried to do something with that green Lucene logo - but it 
really turned out bad: 
https://svn.apache.org/repos/asf/lucene.net/site/images/lucene_net_green_460.GIF


Thanks,
Shad Storhaug (NightOwl888)



-Original Message-
From: Shad Storhaug [mailto:s...@shadstorhaug.com] 
Sent: Tuesday, July 18, 2017 12:05 AM
To: George Kinsman
Cc: dev@lucenenet.apache.org
Subject: RE: New Website

George,

Before I get into responses, what I am thinking would work best is melding 
together the best ideas from these 4 websites we have to draw on:

1. https://simpleinjector.org/index.html
2. https://autofac.org/
3. https://lucenenet.apache.org/
4. https://lucene.apache.org/

The first 2 in terms of design and organization. The second 2 in terms of 
content.

> Those links are great - do you think they should all be as visible as the 
> github/mail list at the top? Maybe that area should be reserved for the most 
> directly useful links? At a glance the might be:
- Github
- Mailing list archives 
- StackOverflow
- Nuget
- JIRA
The others could possibly go in sub-menu's at the top - That way they'd be 
visible (as they're still v important) but not have so much 'air-time' so to 
speak. Thoughts?  

I would consider the link to signing up for the mailing lists (since it 
effectively is Apache's replacement for an issue tracker on GitHub) to trump 
the mail archives, but other than that I agree this looks like a good "short 
list" for the top of the site.

I was hoping you could find the right balance to organization. But as I 
mentioned above, I like the way SimpleInjector organizes the data - in 
particular they have the "Learn", "Use", and "Engage" links at the bottom. 
Autofac also organizes their links similarly. Maybe we need to do some 
re-categorizing because our "Use" category would be full but our "Engage" 
category only has "Contribute" (well, I guess we could put a link to Apache's 
site there and maybe a link to a page with known users of Lucene.Net) and our 
"Learn" only has "Wiki" and "API" (and I guess user list mail archive), but you 
get the general idea. I am pretty sure all of those icons are available as 
fonts via Bootstrap, so doing something like this should be pretty 
straightforward.

That said, those links are just ideas I am putting out there. I don't consider 
this an exhaustive list - I am sure by going through the Lucene and Lucene.Net 
websites there might be a slightly different way to arrange them (for example, 
we should probably make a similar "download" page with all of the info about 
checking the hashes - https://lucenenet.apache.org/download.cgi - and put the 
download latest and archive links on it), and there are probably more links we 
need to uncover.

For example, should we have a Twitter account? Do we have a Twitter account for 
that matter? And maybe we could have a forum someday, but for now I think we 
can rely on the mailing lists and StackOverflow for providing support, since 
both are pretty active with people willing to help.

Oh, and I forgot to mention to link to Lucene's site, and there must be a place 
with better graphics that we can either build or link to that describes what an 
inverted index is (rather than http://lucene.sourceforge.net/talks/pisa/). 

Code 

RE: New Website

[Shad Storhaug]

George,

FYI - I found the source code for the old website: 
https://svn.apache.org/repos/asf/lucene.net/site

I was trying to figure out how the download page 
(http://lucenenet.apache.org/download.cgi) is setup. For example, how does it 
determine what mirror to set as default?, where does it get the mirrors to 
list?, etc. Looks like it is just a wrapper around 
http://www.apache.org/dyn/mirrors/mirrors.cgi. To get the current mirror list 
and "default" mirror we could either use the same approach with cgi or it looks 
like we could do this using JavaScript: 
https://stackoverflow.com/questions/8962757/executing-a-cgi-script-via-javascript

Hah - they also tried to do something with that green Lucene logo - but it 
really turned out bad: 
https://svn.apache.org/repos/asf/lucene.net/site/images/lucene_net_green_460.GIF


Thanks,
Shad Storhaug (NightOwl888)



-Original Message-
From: Shad Storhaug [mailto:s...@shadstorhaug.com] 
Sent: Tuesday, July 18, 2017 12:05 AM
To: George Kinsman
Cc: dev@lucenenet.apache.org
Subject: RE: New Website

George,

Before I get into responses, what I am thinking would work best is melding 
together the best ideas from these 4 websites we have to draw on:

1. https://simpleinjector.org/index.html
2. https://autofac.org/
3. https://lucenenet.apache.org/
4. https://lucene.apache.org/

The first 2 in terms of design and organization. The second 2 in terms of 
content.

> Those links are great - do you think they should all be as visible as the 
> github/mail list at the top? Maybe that area should be reserved for the most 
> directly useful links? At a glance the might be:
- Github
- Mailing list archives 
- StackOverflow
- Nuget
- JIRA
The others could possibly go in sub-menu's at the top - That way they'd be 
visible (as they're still v important) but not have so much 'air-time' so to 
speak. Thoughts?  

I would consider the link to signing up for the mailing lists (since it 
effectively is Apache's replacement for an issue tracker on GitHub) to trump 
the mail archives, but other than that I agree this looks like a good "short 
list" for the top of the site.

I was hoping you could find the right balance to organization. But as I 
mentioned above, I like the way SimpleInjector organizes the data - in 
particular they have the "Learn", "Use", and "Engage" links at the bottom. 
Autofac also organizes their links similarly. Maybe we need to do some 
re-categorizing because our "Use" category would be full but our "Engage" 
category only has "Contribute" (well, I guess we could put a link to Apache's 
site there and maybe a link to a page with known users of Lucene.Net) and our 
"Learn" only has "Wiki" and "API" (and I guess user list mail archive), but you 
get the general idea. I am pretty sure all of those icons are available as 
fonts via Bootstrap, so doing something like this should be pretty 
straightforward.

That said, those links are just ideas I am putting out there. I don't consider 
this an exhaustive list - I am sure by going through the Lucene and Lucene.Net 
websites there might be a slightly different way to arrange them (for example, 
we should probably make a similar "download" page with all of the info about 
checking the hashes - https://lucenenet.apache.org/download.cgi - and put the 
download latest and archive links on it), and there are probably more links we 
need to uncover.

For example, should we have a Twitter account? Do we have a Twitter account for 
that matter? And maybe we could have a forum someday, but for now I think we 
can rely on the mailing lists and StackOverflow for providing support, since 
both are pretty active with people willing to help.

Oh, and I forgot to mention to link to Lucene's site, and there must be a place 
with better graphics that we can either build or link to that describes what an 
inverted index is (rather than http://lucene.sourceforge.net/talks/pisa/). 

Code Samples

I agree with you and like to have the code front and center demonstrating first 
and foremost that the library is easy to use, rather than spending a whole day 
trying to determine whether the library is easy to use by experimenting. The 
only thing I don't like is that when you are down in the API docs you have to 
link offsite from there to view them. There must be some solution where we can 
put them in both places without having to navigate off site and without having 
to duplicate content...

Calling Dispose() in practice cannot be safely done without a try-finally 
block. A using block can be done in fewer lines. Also, I recently discovered 
that you can chain multiple using statements together rather than nesting them, 
which cuts down even more on lines of code and indentation 
(https://github.com/apache/lucene

RE: New Website

[Shad Storhaug]

x. Perhaps I 
should just make the whole thing smaller so it won't be so wide - I could 
probably get it down to 400-450px wide and make a smaller one that is about 2/3 
of that so it isn't so difficult to work with. I could also add a bit of extra 
border so it positions better without having to fix it up with CSS (much like 
the one you have now). Just let me know what works best for the size and I will 
build to that spec.

Also, I could convert that magnifying glass into vector graphics so they scale 
down better. Or we could use a different one. I originally chose it because it 
had a big lens area, so I could put "magnified" content in it for 
BoboBrowse.Net (https://github.com/NightOwl888/BoboBrowse.Net#readme). But if 
there is no content in it we could just as well use a smaller one.

DEMO

I just noticed that Lucene also has a demo search box on their site. I don't 
know what good a search would do on what will likely be a small site with a few 
pages, but it would be a cool feature if we had an interactive online demo of 
Lucene.Net in action, especially if we could put together a faceted search demo 
drilling down into data. Let's consider that a wish list item - a "could have", 
not a "must have".


Thanks,
Shad Storhaug (NightOwl888)


-Original Message-
From: George Kinsman [mailto:geo...@georgekinsman.com] 
Sent: Monday, July 17, 2017 8:22 PM
To: Shad Storhaug
Cc: dev@lucenenet.apache.org
Subject: RE: New Website

Thanks for the comments, they're hugely valuable. I've actioned most of them, 
with some additional thoughts/questions on a few. 

1. Fixed
2/4/5. It's a tricky balance to make I think, that's for sure! Perhaps to make 
the samples more useful we could link classes in the code samples to their 
respective API docs, or the additional getting started docs? I think having an 
example of how the library works on the front page could be important to 
introduce new users, and to act as a kind of lightweight reference for 
returning users. Personally I've found other sites that do this more useful 
than those that require a few clicks/page scanning to reach the 'guts' of a 
library - I tend to try to intellisense from there when playing around. Perhaps 
it is a bit too much code though.

The IDisposable usage is a tricky one - on the one hand the samples should most 
definitely display correct usage, although such usage would break the flow and 
indentation of the display as it's currently divided (with the re-use of the 
writer too). Perhaps it's enough to just call dispose on the 
writer/dir/analyser at the end with a comment? The sample itself could link to 
some docs on how to manage the lifetimes of these objects with IoC in mind:


// Cleanup
writer.Dispose();
dir.Dispose();
analyser.Dispose();


I actually did use that demo code to help fashion those code samples, though 
apart from the obvious IDisposable/spelling error, I'm curious which parts 
you're referring to as extra? The code is runnable with LinqPad after 
installing Lucene.Net.Analyzers.Common (hence why I used that as the nuget 
target, it seemed to be the most necessary package) but I wasn't really able to 
slim it down any further while retaining some runnable code that produced 
something. I toyed with the idea of linking to a downloadable LinqPad sample (I 
used it to write this sample, as evidenced by the `.Dump()` calls) but wanted 
to get feedback first.  I'm not hugely attached to any particular strategy 
here, just that I think having some code is important.

3. Those links are great - do you think they should all be as visible as the 
github/mail list at the top? Maybe that area should be reserved for the most 
directly useful links? At a glance the might be:
- Github
- Mailing list archives 
- StackOverflow
- Nuget
- JIRA
The others could possibly go in sub-menu's at the top - That way they'd be 
visible (as they're still v important) but not have so much 'air-time' so to 
speak. Thoughts?  
6. Totally agree - we stick to American English here too just to match 
conventions with the BCL/style guides. I had it right in the code, but missed 
the title!
7. Good thoughts - fixed.

8. Added to an About section lower down. I wonder if the first goal might need 
a slight update, now that the project isn't so much an automated port but a 
curated one. Super quick idea: ' Maintain a curated port of the Java Lucene 
project in C# that follows the same direction and feature set of the Java 
Lucene project.'

9. As mentioned before I used that one as Lucene.Net seemed to not be very 
useful on its own, but I agree with your thinking - it's the main package. it 
might be worth linking to a page somewhere (or having it further down a bit on 
the main site) that explains each package. I can see there's explanations on 

RE: New Website

[George Kinsman]

Thanks for the comments, they're hugely valuable. I've actioned most of them, 
with some additional thoughts/questions on a few. 

1. Fixed
2/4/5. It's a tricky balance to make I think, that's for sure! Perhaps to make 
the samples more useful we could link classes in the code samples to their 
respective API docs, or the additional getting started docs? I think having an 
example of how the library works on the front page could be important to 
introduce new users, and to act as a kind of lightweight reference for 
returning users. Personally I've found other sites that do this more useful 
than those that require a few clicks/page scanning to reach the 'guts' of a 
library - I tend to try to intellisense from there when playing around. Perhaps 
it is a bit too much code though.

The IDisposable usage is a tricky one - on the one hand the samples should most 
definitely display correct usage, although such usage would break the flow and 
indentation of the display as it's currently divided (with the re-use of the 
writer too). Perhaps it's enough to just call dispose on the 
writer/dir/analyser at the end with a comment? The sample itself could link to 
some docs on how to manage the lifetimes of these objects with IoC in mind:


// Cleanup
writer.Dispose();
dir.Dispose();
analyser.Dispose();


I actually did use that demo code to help fashion those code samples, though 
apart from the obvious IDisposable/spelling error, I'm curious which parts 
you're referring to as extra? The code is runnable with LinqPad after 
installing Lucene.Net.Analyzers.Common (hence why I used that as the nuget 
target, it seemed to be the most necessary package) but I wasn't really able to 
slim it down any further while retaining some runnable code that produced 
something. I toyed with the idea of linking to a downloadable LinqPad sample (I 
used it to write this sample, as evidenced by the `.Dump()` calls) but wanted 
to get feedback first.  I'm not hugely attached to any particular strategy 
here, just that I think having some code is important.

3. Those links are great - do you think they should all be as visible as the 
github/mail list at the top? Maybe that area should be reserved for the most 
directly useful links? At a glance the might be:
- Github
- Mailing list archives 
- StackOverflow
- Nuget
- JIRA
The others could possibly go in sub-menu's at the top - That way they'd be 
visible (as they're still v important) but not have so much 'air-time' so to 
speak. Thoughts?  
6. Totally agree - we stick to American English here too just to match 
conventions with the BCL/style guides. I had it right in the code, but missed 
the title!
7. Good thoughts - fixed.

8. Added to an About section lower down. I wonder if the first goal might need 
a slight update, now that the project isn't so much an automated port but a 
curated one. Super quick idea: ' Maintain a curated port of the Java Lucene 
project in C# that follows the same direction and feature set of the Java 
Lucene project.'

9. As mentioned before I used that one as Lucene.Net seemed to not be very 
useful on its own, but I agree with your thinking - it's the main package. it 
might be worth linking to a page somewhere (or having it further down a bit on 
the main site) that explains each package. I can see there's explanations on 
the github page, but perhaps with more detail.
10. Definitely some great content there! Will look to add some soon, perhaps 
before the new 'About' section but after the code samples. Or maybe before.
11. Hah. Fixed :-).

In terms of logo, are you particularly attached to the Java lucene font/logo? 
I've been browsing through the noun project and have found a few simple logo's 
that have the search icon that could replace the current wavy thing. I'm not 
sure I'm a huge fan of the classic lucene green or the font - it looks a tad 
aged (though that's probably just me.) 

Noun Project ideas:
https://thenounproject.com/term/search/932675/
https://thenounproject.com/term/search/24561/


Anyway, just my 2 cents - hope some of this is helpful :-).

George

-Original Message-----
From: Shad Storhaug [mailto:s...@shadstorhaug.com] 
Sent: Monday, 17 July 2017 6:35 AM
To: George Kinsman 
Cc: dev@lucenenet.apache.org
Subject: RE: New Website

George,

It's a start!

Since you mentioned it, I took a crack at making some logo images by merging 
together the Microsoft .NET logo (look) with the Lucene logo. I am not sure 
what Apache's policy is on one project using another project's logo, so if I 
went horribly wrong here somebody please tell me.

I made one wide logo (490px) for the bigger viewports and a narrow one (200px) 
for the smaller viewport. Not sure if these dimensions will work, but if not 
let me know what might work and I will

RE: New Website

[Shad Storhaug]

alia).


Thanks,
Shad Storhaug (NightOwl888)



-Original Message-----
From: George Kinsman [mailto:geo...@georgekinsman.com] 
Sent: Sunday, July 16, 2017 8:41 PM
To: dev@lucenenet.apache.org
Subject: Re: New Website

Hi there,


I spent some time over the last week on a draft version of a new website. I've 
uploaded a repository to github 
(https://github.com/gkinsman/LuceneNetDraftSite) with the site and build 
scripts. You can run `build.ps1` to do a one time build, and `build.ps1 -watch` 
to start an http server and watch script.


A sample screenshot of it is here: http://i.imgur.com/YR7wSpj.jpg. Obviously 
I've made some assumptions in the sample code, and it's a very rough draft - 
but it's a start, and should be quite easy to add to. I haven't touched the 
logo - I don't have the skills to better the current design.


Let me know your thoughts.

George



From: Shad Storhaug 
Sent: 08 July 2017 17:37
To: dev@lucenenet.apache.org
Subject: RE: New Website

A concern is the amount of maintenance involved with so many tools. We already 
have a lot of them, so it would probably be best to reuse the tools we have if 
possible to keep the learning curve and maintenance of the infrastructure down.

> . I'm not sure how strict the rules are on exactly *what* code needs to be 
> hosted at Apache, but perhaps it might be wise to create a github org for 
> Lucene.Net for non-core repositories. We could then store the static site 
> there, and deploy it to apache.org as per the rules.

The lucenenet project is already part of the Apache GitHub org. I don't think 
it is possible to be part of more than one organization.

I have worked with GitHub pages before and they recommended to set it up as a 
different branch in the same repo. I thought it was a PITA at the time because 
I had to do a git clean every time I switched between branches, but now that I 
think about the workflow a bit more there could just be separate working 
directories for the lucenenet project and the web site each pointing to a 
different branch. So, reusing the current repo (on a separate branch) is a 
possibility. We could also receive PRs for the doc updates, provided we provide 
the instructions where to find them in the repo. And using a different branch 
means we can easily have 2 different CI triggers so they can be independent.


> If we used something like Wyam, content updates would become a matter of 
> changing/adding a new markdown document to the site repository, which could 
> then be built and deployed using AppVeyor<https://www.appveyor.com/> to 
> apache.org.
AppVeyor - Continuous Integration and Deployment service 
...<https://www.appveyor.com/> www.appveyor.com
#1 Continuous Delivery service for Windows Your new build server in a cloud. 
Start in minutes. Enjoy faster results.




No issue with using Wyam. However, we already are using TeamCity for CI and 
should probably just create a separate build for the web site on TeamCity 
(https://teamcity.jetbrains.com/project.html?projectId=LuceneNet_PortableBuilds),
 so we don't have yet another tool to learn/provide permissions for. We are 
also using Powershell for the build script, so it would be best to use 
Powershell in this case as well as a wrapper around whatever tooling needs to 
run (if necessary).

> Let me know your thoughts on what I've outlined above - I'm going to begin 
> working on some ideas for design, which I'll update you with as I go. I'd be 
> happy to set all of the above up, I think it comes down to where you'd be 
> willing to host the static site repository, and whether you want to go down 
> the GitHub org path - assuming you're happy with the direction.

It sounds like you have the right idea. Actually, I like Autofac's design even 
more than SimpleInjector.

Although, it would be nice if some of the rest of the team let us know their 
thoughts as well. Prescott, Stefan, Itamar, Wyatt?

Does anyone know who has or how to get access to update the existing web site, 
or if it is possible to change the DNS record for lucenenet.apache.org to a new 
location? The API docs are hosted on the same subdomain so this applies to that 
project as well.


Recent News/Updates

Frankly, this is another thing that we really should cut out of the design 
unless someone is willing to commit to keeping it updated. If we have a design 
that doesn't have any dates or versions on it, it will always be current and we 
don't run the risk of it looking dead even if nobody touches it for a couple of 
years. I don't see any dates or version numbers on Autofac or SimpleInjector's 
websites. Do we really need to announce to the world that the project teeters 
on the edge of extinction because not enough people contribute? It doesn't 
sound like the right formula to building a successful commu

Re: New Website

[George Kinsman]

Hi there,


I spent some time over the last week on a draft version of a new website. I've 
uploaded a repository to github 
(https://github.com/gkinsman/LuceneNetDraftSite) with the site and build 
scripts. You can run `build.ps1` to do a one time build, and `build.ps1 -watch` 
to start an http server and watch script.


A sample screenshot of it is here: http://i.imgur.com/YR7wSpj.jpg. Obviously 
I've made some assumptions in the sample code, and it's a very rough draft - 
but it's a start, and should be quite easy to add to. I haven't touched the 
logo - I don't have the skills to better the current design.


Let me know your thoughts.

George



From: Shad Storhaug 
Sent: 08 July 2017 17:37
To: dev@lucenenet.apache.org
Subject: RE: New Website

A concern is the amount of maintenance involved with so many tools. We already 
have a lot of them, so it would probably be best to reuse the tools we have if 
possible to keep the learning curve and maintenance of the infrastructure down.

> . I'm not sure how strict the rules are on exactly *what* code needs to be 
> hosted at Apache, but perhaps it might be wise to create a github org for 
> Lucene.Net for non-core repositories. We could then store the static site 
> there, and deploy it to apache.org as per the rules.

The lucenenet project is already part of the Apache GitHub org. I don't think 
it is possible to be part of more than one organization.

I have worked with GitHub pages before and they recommended to set it up as a 
different branch in the same repo. I thought it was a PITA at the time because 
I had to do a git clean every time I switched between branches, but now that I 
think about the workflow a bit more there could just be separate working 
directories for the lucenenet project and the web site each pointing to a 
different branch. So, reusing the current repo (on a separate branch) is a 
possibility. We could also receive PRs for the doc updates, provided we provide 
the instructions where to find them in the repo. And using a different branch 
means we can easily have 2 different CI triggers so they can be independent.


> If we used something like Wyam, content updates would become a matter of 
> changing/adding a new markdown document to the site repository, which could 
> then be built and deployed using AppVeyor<https://www.appveyor.com/> to 
> apache.org.
AppVeyor - Continuous Integration and Deployment service 
...<https://www.appveyor.com/>
www.appveyor.com
#1 Continuous Delivery service for Windows Your new build server in a cloud. 
Start in minutes. Enjoy faster results.




No issue with using Wyam. However, we already are using TeamCity for CI and 
should probably just create a separate build for the web site on TeamCity 
(https://teamcity.jetbrains.com/project.html?projectId=LuceneNet_PortableBuilds),
 so we don't have yet another tool to learn/provide permissions for. We are 
also using Powershell for the build script, so it would be best to use 
Powershell in this case as well as a wrapper around whatever tooling needs to 
run (if necessary).

> Let me know your thoughts on what I've outlined above - I'm going to begin 
> working on some ideas for design, which I'll update you with as I go. I'd be 
> happy to set all of the above up, I think it comes down to where you'd be 
> willing to host the static site repository, and whether you want to go down 
> the GitHub org path - assuming you're happy with the direction.

It sounds like you have the right idea. Actually, I like Autofac's design even 
more than SimpleInjector.

Although, it would be nice if some of the rest of the team let us know their 
thoughts as well. Prescott, Stefan, Itamar, Wyatt?

Does anyone know who has or how to get access to update the existing web site, 
or if it is possible to change the DNS record for lucenenet.apache.org to a new 
location? The API docs are hosted on the same subdomain so this applies to that 
project as well.


Recent News/Updates

Frankly, this is another thing that we really should cut out of the design 
unless someone is willing to commit to keeping it updated. If we have a design 
that doesn't have any dates or versions on it, it will always be current and we 
don't run the risk of it looking dead even if nobody touches it for a couple of 
years. I don't see any dates or version numbers on Autofac or SimpleInjector's 
websites. Do we really need to announce to the world that the project teeters 
on the edge of extinction because not enough people contribute? It doesn't 
sound like the right formula to building a successful community.


Vote

It looks like the last release had a couple of design proposals and the team 
voted on the one they preferred 
(http://apache.markmail.org/message/aafm74wp556dlohm?q=lucenenet+website). 
Sounds 

RE: New Website

[Daniel Kornev]

This just mirrors how we were doing MSDN 2.0 at Microsoft almost a decade ago.



Library had API docs created with the builds of actual apps/systems/sdks by the 
corresponding build servers, and we also had a special tool, PublishThis, for 
adding/editing the rest of the files, and embedding into the library TOC where 
appropriate.



It was quite a pain to keep both things to look alike, but the result paid off.





Sent from my Windows 10 phone



From: Shannon Deminick<mailto:shan...@umbraco.dk>
Sent: Monday, July 10, 2017 4:39 PM
To: dev@lucenenet.apache.org<mailto:dev@lucenenet.apache.org>
Subject: Re: New Website



Hi all,

Just wanted to chime in about the DocFx work and what DocFx supports and
what we could/should use it for (the work in progress PR is here:
https://github.com/apache/lucenenet/pull/206)

There are 2 primary functions of DocFx: Generating API documentation for
.NET libraries as a static html site and using markdown files as static
generated documentation site. DocFx is built in a way that both of these
things can exist side by side. That said, it doesn't mean they should be
especially based on the previous comments, requirements, wishes in this
thread.

DocFx has a templating engine and could very well probably support any sort
of theme you'd want but there doesn't currently seem to be any public
templates showcased apart from the default. The template modifications I've
made with the current DocFx PR is just a few color/icon changes but not
layout (though it is possible). If you are interested, this is the docs for
the templating system:
http://dotnet.github.io/docfx/tutorial/intro_template.html . More
importantly though, that site that you see there is the static generated
documentation site which is build from markdown files and represents what
the default theme mostly looks like. If you click on the "API
Documentation" menu item at the top, you'll see the generated docs based on
the .NET APIs which look quite similar.

I think the API docs generated from DocFx is pretty nice and there are
extensibility points within DocFx to do some things that have been
requested such as extending the Markdown engine to parse custom strings.
Example, in the source there is @lucene.experimental in the API docs and
I've already created a custom parser to turn this into a custom Note block
(similar to this:
https://github.com/dotnet/docfx/issues/1737#issue-234133266 ). I'm pretty
sure we can achieve all of the requirements/questions asked regarding the
API docs with DocFx including incorporating the custom documentation from
the Java Lucene repo (see comment here:
https://github.com/apache/lucenenet/pull/206#issuecomment-301757155) along
with namespace documentation, etc...

However, for the regular documentation, if you want an easy to use custom
site generator that already has some nice theme templates that can be
adjusted than it's probably a better idea to go down that route. Otherwise
I think it will take a lot of time to create a fully customized DocFx theme
that you are happy with for the custom markdown docs. Another benefit of
not using DocFx for the custom docs is that to re-generate the DocFx site
takes a long time because it generates both the API docs and the normal
docs in the same build and there's a ton of APIs so this process isn't
exactly fast.

This would end up with having 2 different site builds: One for custom
written documentation/wiki/etc... and another for API documentation
including code samples and converted docs from the Java Lucene repo. They
will of course look differently but I can match any colors, fonts, etc...
in the API docs to match the regular docs and since they will be both
static file generated sites they can be hosted side by side in different
folders.

Cheers,
Shannon


On Mon, Jul 10, 2017 at 8:37 PM George Kinsman 
wrote:

> I’m with you on tooling – by the sounds of things this workflow would fit
> right in with what already exists – I think the only thing we’d be adding
> is a static site generator. Speaking of which, I took a look at the current
> static gen ecosystem and it actually looks like Hugo (https://gohugo.io/)
> might be a better bet – many more pre-existing themes to adapt, much better
> documentation, wider use. I created a demo install in about 10 minutes that
> just exported to a dist directory that we could FTP or whatever to the
> host. TeamCity setup will be super simple as it’s basically `& hugo -s
> $source -d $dist`.
>
>
>
> It looks like our experiences with github pages seem to match :-). A link
> could be put somewhere (perhaps even per page in generated docs that link
> back to file in repo for ease of editing   like the ‘suggest edit’
> links you see around) that leads to the branch with the site in it where
> people can submit PR’s. They might even be able to be auto-tagged as
> documenta

Re: New Website

[Shannon Deminick]

Hi all,

Just wanted to chime in about the DocFx work and what DocFx supports and
what we could/should use it for (the work in progress PR is here:
https://github.com/apache/lucenenet/pull/206)

There are 2 primary functions of DocFx: Generating API documentation for
.NET libraries as a static html site and using markdown files as static
generated documentation site. DocFx is built in a way that both of these
things can exist side by side. That said, it doesn't mean they should be
especially based on the previous comments, requirements, wishes in this
thread.

DocFx has a templating engine and could very well probably support any sort
of theme you'd want but there doesn't currently seem to be any public
templates showcased apart from the default. The template modifications I've
made with the current DocFx PR is just a few color/icon changes but not
layout (though it is possible). If you are interested, this is the docs for
the templating system:
http://dotnet.github.io/docfx/tutorial/intro_template.html . More
importantly though, that site that you see there is the static generated
documentation site which is build from markdown files and represents what
the default theme mostly looks like. If you click on the "API
Documentation" menu item at the top, you'll see the generated docs based on
the .NET APIs which look quite similar.

I think the API docs generated from DocFx is pretty nice and there are
extensibility points within DocFx to do some things that have been
requested such as extending the Markdown engine to parse custom strings.
Example, in the source there is @lucene.experimental in the API docs and
I've already created a custom parser to turn this into a custom Note block
(similar to this:
https://github.com/dotnet/docfx/issues/1737#issue-234133266 ). I'm pretty
sure we can achieve all of the requirements/questions asked regarding the
API docs with DocFx including incorporating the custom documentation from
the Java Lucene repo (see comment here:
https://github.com/apache/lucenenet/pull/206#issuecomment-301757155) along
with namespace documentation, etc...

However, for the regular documentation, if you want an easy to use custom
site generator that already has some nice theme templates that can be
adjusted than it's probably a better idea to go down that route. Otherwise
I think it will take a lot of time to create a fully customized DocFx theme
that you are happy with for the custom markdown docs. Another benefit of
not using DocFx for the custom docs is that to re-generate the DocFx site
takes a long time because it generates both the API docs and the normal
docs in the same build and there's a ton of APIs so this process isn't
exactly fast.

This would end up with having 2 different site builds: One for custom
written documentation/wiki/etc... and another for API documentation
including code samples and converted docs from the Java Lucene repo. They
will of course look differently but I can match any colors, fonts, etc...
in the API docs to match the regular docs and since they will be both
static file generated sites they can be hosted side by side in different
folders.

Cheers,
Shannon


On Mon, Jul 10, 2017 at 8:37 PM George Kinsman 
wrote:

> I’m with you on tooling – by the sounds of things this workflow would fit
> right in with what already exists – I think the only thing we’d be adding
> is a static site generator. Speaking of which, I took a look at the current
> static gen ecosystem and it actually looks like Hugo (https://gohugo.io/)
> might be a better bet – many more pre-existing themes to adapt, much better
> documentation, wider use. I created a demo install in about 10 minutes that
> just exported to a dist directory that we could FTP or whatever to the
> host. TeamCity setup will be super simple as it’s basically `& hugo -s
> $source -d $dist`.
>
>
>
> It looks like our experiences with github pages seem to match :-). A link
> could be put somewhere (perhaps even per page in generated docs that link
> back to file in repo for ease of editing   like the ‘suggest edit’
> links you see around) that leads to the branch with the site in it where
> people can submit PR’s. They might even be able to be auto-tagged as
> documentation.
>
>
>
> I tend to agree with you about posting updates – I think most projects
> these days keep a blog, or just use twitter for release announcements and
> rely on community blogging.
>
>
>
> I’ll have a stab at adapting some of the ideas from the JIRA thread to
> Hugo and see how I go.
>
>
>
> Cheers,
>
> George
>
> 
> From: Shad Storhaug 
> Sent: 08 July 2017 17:37
> To: dev@lucenenet.apache.org
> Subject: RE: New Website
>
> A concern is the amount of maintenance involved with so many tools. We
> already have a lot of t

Re: New Website

[George Kinsman]

I’m with you on tooling – by the sounds of things this workflow would fit right 
in with what already exists – I think the only thing we’d be adding is a static 
site generator. Speaking of which, I took a look at the current static gen 
ecosystem and it actually looks like Hugo (https://gohugo.io/) might be a 
better bet – many more pre-existing themes to adapt, much better documentation, 
wider use. I created a demo install in about 10 minutes that just exported to a 
dist directory that we could FTP or whatever to the host. TeamCity setup will 
be super simple as it’s basically `& hugo -s $source -d $dist`.



It looks like our experiences with github pages seem to match :-). A link could 
be put somewhere (perhaps even per page in generated docs that link back to 
file in repo for ease of editing   like the ‘suggest edit’ links you see 
around) that leads to the branch with the site in it where people can submit 
PR’s. They might even be able to be auto-tagged as documentation.



I tend to agree with you about posting updates – I think most projects these 
days keep a blog, or just use twitter for release announcements and rely on 
community blogging.



I’ll have a stab at adapting some of the ideas from the JIRA thread to Hugo and 
see how I go.



Cheers,

George


From: Shad Storhaug 
Sent: 08 July 2017 17:37
To: dev@lucenenet.apache.org
Subject: RE: New Website

A concern is the amount of maintenance involved with so many tools. We already 
have a lot of them, so it would probably be best to reuse the tools we have if 
possible to keep the learning curve and maintenance of the infrastructure down.

> . I'm not sure how strict the rules are on exactly *what* code needs to be 
> hosted at Apache, but perhaps it might be wise to create a github org for 
> Lucene.Net for non-core repositories. We could then store the static site 
> there, and deploy it to apache.org as per the rules.

The lucenenet project is already part of the Apache GitHub org. I don't think 
it is possible to be part of more than one organization.

I have worked with GitHub pages before and they recommended to set it up as a 
different branch in the same repo. I thought it was a PITA at the time because 
I had to do a git clean every time I switched between branches, but now that I 
think about the workflow a bit more there could just be separate working 
directories for the lucenenet project and the web site each pointing to a 
different branch. So, reusing the current repo (on a separate branch) is a 
possibility. We could also receive PRs for the doc updates, provided we provide 
the instructions where to find them in the repo. And using a different branch 
means we can easily have 2 different CI triggers so they can be independent.


> If we used something like Wyam, content updates would become a matter of 
> changing/adding a new markdown document to the site repository, which could 
> then be built and deployed using AppVeyor<https://www.appveyor.com/> to 
> apache.org.
AppVeyor - Continuous Integration and Deployment service 
...<https://www.appveyor.com/>
www.appveyor.com
#1 Continuous Delivery service for Windows Your new build server in a cloud. 
Start in minutes. Enjoy faster results.




No issue with using Wyam. However, we already are using TeamCity for CI and 
should probably just create a separate build for the web site on TeamCity 
(https://teamcity.jetbrains.com/project.html?projectId=LuceneNet_PortableBuilds),
 so we don't have yet another tool to learn/provide permissions for. We are 
also using Powershell for the build script, so it would be best to use 
Powershell in this case as well as a wrapper around whatever tooling needs to 
run (if necessary).

> Let me know your thoughts on what I've outlined above - I'm going to begin 
> working on some ideas for design, which I'll update you with as I go. I'd be 
> happy to set all of the above up, I think it comes down to where you'd be 
> willing to host the static site repository, and whether you want to go down 
> the GitHub org path - assuming you're happy with the direction.

It sounds like you have the right idea. Actually, I like Autofac's design even 
more than SimpleInjector.

Although, it would be nice if some of the rest of the team let us know their 
thoughts as well. Prescott, Stefan, Itamar, Wyatt?

Does anyone know who has or how to get access to update the existing web site, 
or if it is possible to change the DNS record for lucenenet.apache.org to a new 
location? The API docs are hosted on the same subdomain so this applies to that 
project as well.


Recent News/Updates

Frankly, this is another thing that we really should cut out of the design 
unless someone is willing to commit to keeping it updated. If we have a design 
that doesn't have any dates or versions on it, it will always be current a

RE: New Website

[Shad Storhaug]

A concern is the amount of maintenance involved with so many tools. We already 
have a lot of them, so it would probably be best to reuse the tools we have if 
possible to keep the learning curve and maintenance of the infrastructure down.

> . I'm not sure how strict the rules are on exactly *what* code needs to be 
> hosted at Apache, but perhaps it might be wise to create a github org for 
> Lucene.Net for non-core repositories. We could then store the static site 
> there, and deploy it to apache.org as per the rules.

The lucenenet project is already part of the Apache GitHub org. I don't think 
it is possible to be part of more than one organization.

I have worked with GitHub pages before and they recommended to set it up as a 
different branch in the same repo. I thought it was a PITA at the time because 
I had to do a git clean every time I switched between branches, but now that I 
think about the workflow a bit more there could just be separate working 
directories for the lucenenet project and the web site each pointing to a 
different branch. So, reusing the current repo (on a separate branch) is a 
possibility. We could also receive PRs for the doc updates, provided we provide 
the instructions where to find them in the repo. And using a different branch 
means we can easily have 2 different CI triggers so they can be independent.


> If we used something like Wyam, content updates would become a matter of 
> changing/adding a new markdown document to the site repository, which could 
> then be built and deployed using AppVeyor to 
> apache.org.

No issue with using Wyam. However, we already are using TeamCity for CI and 
should probably just create a separate build for the web site on TeamCity 
(https://teamcity.jetbrains.com/project.html?projectId=LuceneNet_PortableBuilds),
 so we don't have yet another tool to learn/provide permissions for. We are 
also using Powershell for the build script, so it would be best to use 
Powershell in this case as well as a wrapper around whatever tooling needs to 
run (if necessary).

> Let me know your thoughts on what I've outlined above - I'm going to begin 
> working on some ideas for design, which I'll update you with as I go. I'd be 
> happy to set all of the above up, I think it comes down to where you'd be 
> willing to host the static site repository, and whether you want to go down 
> the GitHub org path - assuming you're happy with the direction.

It sounds like you have the right idea. Actually, I like Autofac's design even 
more than SimpleInjector.

Although, it would be nice if some of the rest of the team let us know their 
thoughts as well. Prescott, Stefan, Itamar, Wyatt?

Does anyone know who has or how to get access to update the existing web site, 
or if it is possible to change the DNS record for lucenenet.apache.org to a new 
location? The API docs are hosted on the same subdomain so this applies to that 
project as well.


Recent News/Updates

Frankly, this is another thing that we really should cut out of the design 
unless someone is willing to commit to keeping it updated. If we have a design 
that doesn't have any dates or versions on it, it will always be current and we 
don't run the risk of it looking dead even if nobody touches it for a couple of 
years. I don't see any dates or version numbers on Autofac or SimpleInjector's 
websites. Do we really need to announce to the world that the project teeters 
on the edge of extinction because not enough people contribute? It doesn't 
sound like the right formula to building a successful community.


Vote

It looks like the last release had a couple of design proposals and the team 
voted on the one they preferred 
(http://apache.markmail.org/message/aafm74wp556dlohm?q=lucenenet+website). 
Sounds like a great way to have community involvement...but if there is only 
time for one design proposal I will vote on it :).



-Original Message-
From: George Kinsman [mailto:geo...@georgekinsman.com] 
Sent: Saturday, July 8, 2017 9:48 AM
To: dev@lucenenet.apache.org
Subject: Re: Mailing List Documentation

SimpleInjector's site looks really good, although as you say it's important to 
have some code samples on the homepage too. Some examples of project homepages 
that I think do a really good job at this include 
Serilog, Autofac and 
Nancy. Each of them have clean designs, code samples, and 
installation directions - and each of them are great examples of very active 
.NET open source projects too. I think we could implement a nice modern design 
with these things front and centre, which would give the project a great web 
presence.


Where

Each of those projects are hosted using Github 
Pages, which is a static content host. They use 
static generator tools like Jekyll to convert markdown from a git repository 
into a plain html website. If we used something a lit