+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 <[email protected]> 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 ([email protected]) wrote: > > > On Apr 3, 2014, at 6:57 PM, Yonik Seeley <[email protected]> wrote: > > On Thu, Apr 3, 2014 at 6:24 PM, Grant Ingersoll <[email protected]> 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: [email protected] > For additional commands, e-mail: [email protected] > > > -------------------------------------------- > Grant Ingersoll | @gsingers > http://www.lucidworks.com > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
