+1 to making the CWiki the One True Source (tm) for Solr documentation.

Rip the damn band-aid off. Deal with the screams by asking anyone with
a beef to contribute to the CWiki. Not quite sure the mechanism here
though. Maybe Cassandra and Hoss have some thoughts here?

The point is that I want to make the burden on the maintainers of the
CWiki as light as possible in terms of adding new content. Currently,
there's a lightweight mechanism for people to add to the Wiki. I'm
thinking we wouldn't open up the CWiki the same way, but could we
maybe have a "scratch pad" area where volunteers could create pages
that could be copy/pasted into the CWiki? For instance, the analytics
component has a bunch of documentation with it. How can we incorporate
it as painlessly as possible?

Locking down the Wiki would add to the message that the Wiki wasn't
where the action is. We still need the "tips and tricks" section.
Hmmm, how about "tips, tricks, and the best of the user's list"?

FWIW,
Erick



On Sun, Apr 6, 2014 at 3:12 AM, Grant Ingersoll <gsing...@apache.org> wrote:
> While I somewhat agree with both the points of Furkan and Alexandre, I am
> not sure which way you are leaning:  Should we pull off the band-aid or not?
> And do no other committers have an opinion here?
>
> -Grant
>
> On Apr 5, 2014, at 6:25 PM, Furkan KAMACI <furkankam...@gmail.com> wrote:
>
> | I think an interesting side-effect issue here is user perception. I
> | feel that ElasticSearch (yet, them) get a lot of points not only
> | because of features (not discussing that here) but because they
> | actually have taken time to put a polish on the SEO, onboarding and
> | other human perception aspects.
>
> that is exactly true. Search that on Google: solr search parameters and have
> a look at the results. Then search that: elasticsearch search parameters.
> You can feel that there has been done a work for SEO at elasticsearch side.
>
> When I started to learn Solr I read every thing, every thing that I can
> find. These include Solr wiki, books, websites about Solr and every e-mail
> at mail list. However is it usual that there were still some pages at wiki
> that I've not seen it before. I've clicked every link at wiki but there was
> some hidden(!) pages that I could not achieve to see it. For example every
> body knows that Shawn has a page tells something about GC tunning for Solr.
> Do you know that how to reach that page when you start to read the wiki?
>
> Reference guide is pretty good. It is like a book for Solr. You start to
> read and when you finish it you get a good knowledge about Solr. My
> suggestion is that: We can rich the Solr guide with links to some external
> pages if it is necessary. On the other hand we can design a nice web site
> that explains Solr feautures as like elasticsearch.
>
> I "personally" separate people into four main categories who works with
> Solr:
>
> First category: He uses Solr, wants to improve search performance, tunning
> etc. etc. but do not know the implementation details very much.
> Second category: He is interesting about scalability, tunning etc. of Solr.
> Third category: He is interesting about linguistic/search part of Solr
> (Lucene).
> Forth category: He is interesting about developing Solr.
>
> So, a wiki should point to the people who uses it, who wants to operate it,
> who wants to improve search benefit and who wants to develop it. My personal
> idea is that: first category is very important too. When you read the guide
> of Elasticsearch it is simple and explains the main things (i.e. you can
> compare the analyzer page at Elasticsearch and Solr). People want to startup
> a system and do not want to do much more thing (I know it is impossible). We
> can help address to such kind of audience too (I know that Solr and
> Elasticsearch audince are not same). I mean a web page explains Solr as like
> elasticsearch and a guide (with links to other resources) that addresses to
> both four category would be nice.
>
> All in all I would want to help Solr for such kind of documentation (I can
> work with Alexandre collaboratively). It would be nice if we have something
> like that.
>
> Thanks;
> Furkan KAMACI
>
>
>
> 2014-04-05 6:21 GMT+03:00 Alexandre Rafalovitch <arafa...@gmail.com>:
>>
>> +1 on consolidating to the Reference Guide and figuring out the way to
>> make wiki a lot less visible. But for a completely different set of
>> reasons than discussed already.
>>
>> [[rant-start]]
>>
>> I think an interesting side-effect issue here is user perception. I
>> feel that ElasticSearch (yet, them) get a lot of points not only
>> because of features (not discussing that here) but because they
>> actually have taken time to put a polish on the SEO, onboarding and
>> other human perception aspects.
>>
>> Solr's messaging is - like many of Apache projects - deeply technical,
>> self-referential and on the main path puts Development before Use
>> (literally, by the order of the wiki sections). Which is _no longer_
>> representative of the users' needs.
>>
>> Reference guide is a large step in the right direction. Commercial
>> distributions also do their best to do the messaging right, even if
>> often at the expense of pushing Solr into an implementation detail
>> (Cloudera!).
>>
>> But I think this is a case of the tide raising all (Solr-based) boats.
>> Somebody with UX skills can probably deconstruct and reconstruct the
>> user experience and the same information will have a lot more impact.
>>
>> This even applies to technical issues as well. Elastic Search has
>> great success talking about schema-less design and Solr relegates its
>> equivalence to a small section deep in the Wiki/Guide. Same with
>> real-time updates. That's because the site/documentation is organized
>> from the implementation rather than impact points of view.
>>
>> If somebody has resources to throw at this, I would start from the UX
>> and user-onboarding part. Maybe even do that for both Lucene and Solr
>> to emphasize common links. And I would be happy to work with someone
>> on that too. Maybe, there is even a need for a separate
>> super-duper-happy-solr-path mailing group to specialize on that.
>> Something that commercial companies can temporarily throw other
>> non-dev resources at, when required.
>>
>> [[rant-end]]
>>
>> Regards,
>>    Alex.
>> P.s. There is a LOT more to the rant, with specific suggestions. And I
>> am walking my talk too (book, solr-start, my nascent mailing list, and
>> a ToDo list to last me next several years of fun projects).
>>
>> Personal website: http://www.outerthoughts.com/
>> Current project: http://www.solr-start.com/ - Accelerating your Solr
>> proficiency
>>
>> On Fri, Apr 4, 2014 at 9:09 PM, Mark Miller <markrmil...@gmail.com> wrote:
>> > I'm not too worried about locking anything down, but the current
>> > situation
>> > is quite confusing. It can be hard to tell what docs you should be
>> > looking
>> > at for a new user.
>> >
>> > I've started putting big warnings and links on a couple important pages
>> > for
>> > the old Wiki, but we should really a do a lot more to make it clear that
>> > the
>> > old wiki system is not our documentation. All signs should point to
>> > cwiki.
>> >
>> > --
>> > Mark Miller
>> > about.me/markrmiller
>> >
>> > On April 4, 2014 at 9:46:02 AM, Grant Ingersoll (gsing...@apache.org)
>> > wrote:
>> >
>> >
>> > On Apr 3, 2014, at 6:57 PM, Yonik Seeley <yo...@heliosearch.com> wrote:
>> >
>> > On Thu, Apr 3, 2014 at 6:24 PM, Grant Ingersoll <gsing...@apache.org>
>> > wrote:
>> >
>> > Lock down the Solr Wiki
>> >
>> > [...]
>> >
>> > the Wiki should simply be tips, tricks, etc. and is NOT official
>> > documentation and committers, for the most part, don't worry about
>> > curating
>> > content there.
>> >
>> >
>> > These two things seem incompatible.  If wiki pages on tips, tricks,
>> > etc continue to be permitted, how does one "Lock down the Solr Wiki"?
>> >
>> >
>> > I mean lock down the current stuff, move it to an archive area (see if
>> > we
>> > can make it read-only) and replace the landing page with just the
>> > community/tips/tricks sections that are there.
>> >
>> >
>> > -Yonik
>> > http://heliosearch.org - solve Solr GC pauses with off-heap filters
>> > and fieldcache
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> > For additional commands, e-mail: dev-h...@lucene.apache.org
>> >
>> >
>> > --------------------------------------------
>> > Grant Ingersoll | @gsingers
>> > http://www.lucidworks.com
>> >
>> >
>> >
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>
>
> --------------------------------------------
> Grant Ingersoll | @gsingers
> http://www.lucidworks.com
>
>
>
>
>

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

Reply via email to