Open WardCunningham opened 8 years ago
almereyda
commented
8 years ago Hi @WardCunningham, instead of improving a centralized federation search service, I'd propose to investigate distributed search and caching backends which would offer a first step towards a resilient wiki search service. Would it make sense to compile a list of candidates, or would an approach favouring implementation over theoretical discussion avoid such a step?
opn
commented
8 years ago yes - let's start researching how to do this - I've made a provisional index of search tools that we might be able to use - some Node based ones and some open source alternatives to Google site search - also some notes on sitemaps here - http://future.fedwiki.org/search-research.html
WardCunningham
commented
8 years ago @almereyda I agree. I suggest moving forward with this code in order to create the demand for a better version. How this might work would be discussed in issues under wiki-plugin-search.
I see little point in improving a centralized search as it will discourage building a distributed search that would enhance the notion of neighborhoods. I've described one vision for how distributed search could work.
http://ward.asia.wiki.org/view/distributed-search
The feature I describe as 'more' is implemented in https://github.com/fedwiki/wiki-client/pull/132 which I would like to explore in practice.
Since starting this project I have become familiar with the awesome capabilities of ElasticSearch. I also note that ElasticSearch as a service is available at about $40 a month. My personal goal for search is to make a distributed version that outperforms any centralized version by making its incremental nature a feature. ElasticSearch is plan b.
almereyda
commented
8 years ago "I suggest moving forward with this code in order to create the demand for a better version."
I feel intruiged, but once again in the same time well-taught by this blatant example of what some people started half of my life ago: http://agilemanifesto.org/ Will need some decommercialized reframing in words, yet mere practice remains.
On 24 November 2015 at 17:11, Ward Cunningham notifications@github.com wrote:
@almereyda https://github.com/almereyda I agree. I suggest moving forward with this code in order to create the demand for a better version. How this might work would be discussed in issues under wiki-plugin-search.
I see little point in improving a centralized search as it will discourage building a distributed search that would enhance the notion of neighborhoods. I've described one vision for how distributed search could work.
http://ward.asia.wiki.org/view/distributed-search
The feature I describe as 'more' is implemented in fedwiki/wiki-client#132 https://github.com/fedwiki/wiki-client/pull/132 which I would like to explore in practice.
Since starting this project I have become familiar with the awesome capabilities of ElasticSearch. I also note that ElasticSearch as a service is available at about $40 a month. My personal goal for search is to make a distributed version that outperforms any centralized version by making its incremental nature a feature. ElasticSearch is plan b.
— Reply to this email directly or view it on GitHub https://github.com/fedwiki/wiki/issues/69#issuecomment-159317650.
paul90
commented
8 years ago I think as a rule, I would like the repos for plugins that are part of the standard wiki distribution to in the fedwiki GitHub organization. Of course, the necessary GitHub organization configuration will be done such that the person contribution the repo retains write access.
For npm, it would be good to add the core team as owners - using npm owner add <user> <package> with the current team being ward, nrn and paul90.
In the meantime, as you know, the search and transport plugins have been included in the latest wiki distribution.
paul90
commented
8 years ago whoops, clicked the wrong button :blush:
WardCunningham
commented
8 years ago Yes, absolutely agree.
Perhaps the documented procedure should go something like this:
If this sounds right, I will get caught up with the ownership transfer and revise the contributing doc.
paul90
commented
8 years ago Sounds good
WardCunningham
commented
8 years ago How can we confirm that contributions adhere to our conventions? I depend on @paul90 to tweak build scripts and package versions but this doesn't seem right. One simple approach would be to include an industrial strength version of mkplugin.sh in the repo and keep its build and package.json up to date. What do other projects do?
paul90
commented
8 years ago That is one option, the other would be to have a template repository using a tool like grunt-init
WardCunningham
commented
8 years ago Ok, I'll look at grunt-init. Thanks for the tip.
Please consider including the Search plugin in the standard wiki distribution.
I have been holding onto this hoping to work out better plugin catalog mechanisms but don't want to hold it up any longer. Instead I would like to establish criteria by which we would accept new plugins.
See also #68
https://github.com/WardCunningham/wiki-plugin-search https://www.npmjs.com/package/wiki-plugin-search
There are no outstanding issues for this plugin. The plugin is dependent on a scrape/search service prototype that I host at search.fed.wiki.org. I know how this could be converted to elasticsearch but have not done so because of low search traffic and the experimental opportunities for new kinds of search.
I have been holding onto https://github.com/fedwiki/wiki-client/pull/132 which adds a novel associative search to every page. I will advance this request once the search plugin that it uses has been published.
I am happy to invoke whatever github and npm ownership transfers are appropriate. Help me develop a checklist for such transfers. Thank you.