Contributing Wiki Plugin Search

[WardCunningham]

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 fedwiki/wiki-client#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.

[almereyda]

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]

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]

@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 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]

"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
fedwiki/wiki-client#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
#69 (comment).

[paul90]

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]

whoops, clicked the wrong button 😊

[WardCunningham]

Yes, absolutely agree.

Perhaps the documented procedure should go something like this:

• Contributor authors plugin, github repo, npm module.
• Contributor posts issue to wiki repo offering plugin for evaluation.
• We publish beta version of wiki with plugin included in package.json.
• Community evaluation discussed in issue, Contributor responds.
• Contributor transfers ownership of both repo and npm package.
• We release semantically versioned update of wiki.

If this sounds right, I will get caught up with the ownership transfer and revise the contributing doc.

[paul90]

Sounds good

[WardCunningham]

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]

That is one option, the other would be to have a template repository using a tool like grunt-init

[WardCunningham]

Ok, I'll look at grunt-init. Thanks for the tip.