Open ferdi05 opened 2 years ago
Some more thoughts from a meeting:
Decide on our policy about going back to older content to update it in light of more recent changes - or add a warning (other solutions possible…). Changing words like the name of an API - can make a global change. Signposting from old post version to new is one way to do this. Maybe draft a policy based on the type of change - name, breaking change, code examples, hacks which are now supported etc, and how to update accordingly.
This outdated blog post still has a lot of readers. It needs to be reworked.
I am wondering about how we could update it, given the fact that it was written by an external contributor. Are we "allowed" to modify it? Or is it better to rewrite a new post with the same dataset and recycle the content as much as possible?
That's a good question. I don't know who arranged this contribution back then. Do you know @tpayet ? thanks
I did. Riccardo was a contractor for Meilisearch. If we are going to update this content we should as well change the author or add the authors who will do this update.
I don't really know how this kind of contracts work, does this mean that we own his content and are able to update it to our will?
Yes we own it
Given the particularities of the mentioned post I added a warning directing readers to the meilisearch-react repo.
When going through old blog posts, I realized we have some other small changes to make, not recurring ones but should be done:
What to do with posts like MeiliSearch in production: taking it to the next level? This post was added at the time to the documentation and is kept up to date in the docs but not in the blog. A warning with a link to the docs? Or since it's duplicate content, could we just remove it?
Blog post | Integrations | Features | Comments |
---|---|---|---|
Search for Rust crates with Meili | Points to MeiliDB | ||
Meilisearch finds Rubygems | meilisearch-ruby | Custom ranking rules | Mentions hosting the demo on a Kubernetes cluster |
How to integrate a relevant search bar to your documentation | docs-scraper, vue-press-plugin, docs-searchbar.js | Moved from the blog to the docs | |
How to Search Nobel Prize Winners Faster With MeiliSearch and JavaScript | meilisearch-js | stopWords, ⚠️attributesForFaceting, ⚠️ranking rules (wordsPosition), custom ranking rules | Links to sandbox |
How to Speed Up GoodReads Book Titles Search With MeiliSearch and JavaScript | meilisearch-js | ⚠️attributesForFaceting, ⚠️facetsDistribution (0 values), distinct attribute, searchableAttributes, ⚠️nested objects | headers, dataset is on the writers repo not in the organization |
How to Add Relevant Search to Your Strapi App Using MeiliSearch | strapi-plugin-meilisearch | Strapi v3 → already has a warning | |
How to integrate an extremely fast and relevant search into your Rails app using Meilisearch and React | meilisearch-rails v0.3.0, instant-meilisearch | displayed, searchable and filterable attributes, faceted search | |
How to integrate a relevant search into Strapi v4 using Meilisearch | strapi-plugin-meilisearch | ||
Add a search bar to your Gatsby project using Meilisearch | gatsby-meilisearch-plugin, docs-searchbar.js | ||
How to use Meilisearch in your multi-tenant application | meilisearch-js | generateTenantToken, apiKeys, createKey | need to clone boilerplate |
I think that articles, where someone shares their experience creating a demo or similar, should not be subject to updates. That's the case for instance of:
If, as in the case of Meilisearch: a blank canvas there is some trick to work around a "problem" solved by a newer version, a note like the one below could be added:
The workarounds described in this blogpost are no longer necessary due to the addition of new features in more recent versions of Meilisearch.
It can also be the opportunity to write a new blog post (like we did with The Art of Sorting)
Tutorials, however, could be updated to comply with the latest version of Meilisearch.
In the case of tutorials about plugins such as Strapi or Gatsby, if the breaking changes come from their side (Strapi v3 vs Strapi v4), a new tutorial should be written to advertise the new integration.
added at the time to the documentation
I'd remove it from the blog if it's fine by @eskombro ?
I think that articles, where someone shares their experience creating a demo or similar, should not be subject to updates. That's the case for instance of:
- Meilisearch finds Rubygems,
- Search for Rust crates with Meili
If, as in the case of Meilisearch: a blank canvas there is some trick to work around a "problem" solved by a newer version, a note like the one below could be added:
The workarounds described in this blogpost are no longer necessary due to the addition of new features in more recent versions of Meilisearch.
It can also be the opportunity to write a new blog post (like we did with The Art of Sorting)
Tutorials, however, could be updated to comply with the latest version of Meilisearch.
In the case of tutorials about plugins such as Strapi or Gatsby, if the breaking changes come from their side (Strapi v3 vs Strapi v4), a new tutorial should be written to advertise the new integration.
I do agree with everything, thanks and congrats @CaroFG for this awesome work.
I guess the next step would be to decide how we're going to do this!
Some tools to audit our current content: see section 2 - Audit your content from Hubspot guide on Content Distribution
I went through the Nobel Prize winners' blog post and have listed all the changes we'll need to do to update it. Besides the changes related to the new naming guidelines and the cover, we should make modifications to the following parts:
Introduction:
Step 1:
Code snippet:
listIndexes
with getIndexes
name
property which will be removed completely in v0.28Step 2:
In the following steps:
const index = client.getIndex('prizes')
with const index = client.index('prizes')
Step 2.1:
updateId
is now uid
update methods
could be renamed to tasks
Step 4:
GET /settings
responseStep 5:
facet filters for strings and arrays of strings
attributesForFaceting
are now filterableAttributes
facetFilters: [ 'category:Chemistry' ]
⇒ filter: 'category = Chemistry'
Step 6:
This whole step should be removed or updated (got to think how) because it relies on the extinct wordsPosition
ranking rule to show how to tune relevancy
Step 6.1
Showcases the custom ranking rule
playing with the year attribute which is a string. We could try and update it to showcase the sorting
feature.
It would require changing the dataset: transform the year which is a string into an integer to have a proper sorting.
Conclusion:
The mention to the sandbox could be replaced with a mention to the cloud.
added at the time to the documentation
I'd remove it from the blog if it's fine by @eskombro ?
Sure! No problem, you can remove it from the blog if you think is better, now it lives in the docs :)
thanks @eskombro I'm unpublishing it
I went through the Nobel Prize winners' blog post and have listed all the changes we'll need to do to update it. Besides the changes related to the new naming guidelines and the cover, we should make modifications to the following parts:
Awesome work @CaroFG, thanks. Happy to hear about your findings and thoughts about how this could apply to any former blog posts. Thanks!
I think the tutorial How to integrate a relevant search bar to your documentation could also be unpublished because it's outdated and lives now in the documentation as a cookbook
I went through the Nobel Prize winners' blog post and have listed all the changes we'll need to do to update it. Besides the changes related to the new naming guidelines and the cover, we should make modifications to the following parts:
Awesome work @CaroFG, thanks. Happy to hear about your findings and thoughts about how this could apply to any former blog posts. Thanks!
The content of this article is highly related to How to Speed Up GoodReads Book Titles Search With MeiliSearch and JavaScript, once we have updated the meilisearch-js
functions in one we can do the same for the other and save time.
The rest of the tutorials are more recent and don't present the same outdated features.
We may want to wait until the release of v0.28 to make the necessary modifications since there are a lot a changes in the API endpoints, and there might be a lot of breaking changes on the SDKs side
Given the particularities of the mentioned post I added a warning directing readers to the meilisearch-react repo.
If this tutorial is already well-positioned regarding SEO, it might be worth the effort to update it, instead of creating a new one. But I think it might require a lot of modifications
I went through the How to implement Instant Search within 5 minutes in your React App! blog post, below you'll find the list of the changes we need to make to update it:
Blog post:
Code:
url("/cover.jpg");
=> url("/public/cover.jpg");
class
=> className
client.getIndex("decathlon");
=> client.index("decathlon");
src/index.js: Warning ReactDOM.render is no longer supported in React 18.
import React from 'react';
import { createRoot } from 'react-dom/client';
import App from './App';
import './index.css';
import * as serviceWorker from './serviceWorker';
const container = document.getElementById('root');
const root = createRoot(container);
root.render(<App/>);
// If you want your app to work offline and load faster, you can change
// unregister() to register() below. Note this comes with some pitfalls.
// Learn more about service workers: https://bit.ly/CRA-PWA
serviceWorker.unregister();
There are no major changes to be made. The main question is what to do with the code, which is hosted in the personal repository of the original author. Either we make a PR or create a repository under the Meilisearch organization and credit the original author in the README. I believe that the latter option is the most appropriate.
Also, if we update the blog post, we should add an extra author and an explanatory note.
WDYT @ferdi05?
I think the tutorial How to integrate a relevant search bar to your documentation could also be unpublished because it's outdated and lives now in the documentation as a cookbook
I'm sorry I missed this earlier :( Would it be ok with you @curquiza ?
- "Live application: https://meili-react-demo.netlify.app/" => No longer live, remove or update this Is it worth hosting this demo somewhere? I must say I never played with it so I have no idea how cool it is
There are no major changes to be made. The main question is what to do with the code, which is hosted in the personal repository of the original author. Either we make a PR or create a repository under the Meilisearch organization and credit the original author in the README. I believe that the latter option is the most appropriate.
The latter sounds good to me
Also, if we update the blog post, we should add an extra author and an explanatory note.
Absolutely, sounds good to me
Would it be ok with you @curquiza ?
We could update it, but it's still a relevant content for people wanting to add a search bar easily to their blog/doc, so not sure removing it is really a good idea
I discussed this with @curquiza and there was a misunderstanding. We agreed to remove her post from the blog, will take of this now cc @CaroFG
The tutorial previously named "How to implement Instant Search within 5 minutes in your React App!" has been updated and renamed to "How to implement instant search in your React app", the URL has also been updated to the following: https://blog.meilisearch.com/instant-search-react-app/, which is the one it had before the Ghost transition and is better positioned regarding SEO, according to Fathom.
All mentions of Meilisearch spelled with capital s have been removed from the blog, and mentions to the sandbox have been replaced to mentions to the cloud
All tutorials have been updated and should work with Meilisearch v1
Awesome, thanks so much @CaroFG !
Our blog posts have publication date, so it can be ok to leave them be out of date. But it's even better if we're able to update them! Let's try doing this. To do so, we would first need a table to see which feature/propgramming language/integration... is used in each post. It would give us a clear view of what should be updated each time we introduce breaking changes.