Passer à des documents agiles et open source

Passer à des documents agiles et open source

“Open source” a beaucoup de sens dans le monde de la technologie de nos jours. Vingt ans après l’invention du terme, les projets open source exploitent la puissance des contributeurs volontaires pour produire et prendre en charge des logiciels dont l’impact augmente rapidement dans chaque industrie, dans chaque lieu.

À la base, l’open source signifie simplement qu’un produit est livré avec le code qui a été écrit pour le produire. La possibilité d’accéder à ce code source crée un potentiel de modification et de reconditionnement régi par diverses licences open source. Cela peut également permettre aux gens de contribuer des modifications dans le projet principal, afin que tout le monde bénéficie de ces modifications.

En tant qu’éditeur de logiciels construit sur les principes de fournir un service supérieur tout en promouvant le bien commun, nous à Redis a décidé d’apporter cette agilité open source à un domaine moins connu, mais très percutant : la documentation produit.

Nous pensons que joindre l’open source à la documentation est une excellente combinaison pour fournir à notre communauté :

  • Des informations toujours à jour
  • Une plate-forme pour les contributions collaboratives des autres
  • Détails très précis d’une communauté dédiée

Pour savoir comment vous pouvez contribuer, consultez notre guide des cotisations.

Alors pourquoi avons-nous décidé d’emprunter la voie open source pour la documentation ? Pour comprendre, regardons l’évolution de la documentation technique au cours des dernières années.

La dernière révolution – Combler l’écart de livraison

Auparavant, la documentation était une pierre d’achoppement dans les délais de développement de logiciels, car toutes les explications prises en charge entourant l’utilisation du logiciel devaient être fournies en même temps que le logiciel lui-même. Pire encore, il a commencé sous forme de matériel imprimé (pensez aux guides de l’utilisateur !) Non seulement lent à créer, mais encore plus difficile à mettre à jour.

Heureusement, au fur et à mesure que la technologie progressait, nous avons pu mettre à jour la documentation utilisateur au format numérique, ce qui nous a permis d’économiser sur les coûts « lourds » d’impression et d’expédition. Les rédacteurs pourraient fournir des corrections, des réécritures et des mises à jour aux clients aussi facilement que les ingénieurs pourraient fournir des correctifs aux logiciels.

Cette révolution a comblé l’écart de livraison pour permettre aux entreprises d’améliorer la documentation pendant la durée de vie du produit. Cependant, d’importants goulots d’étranglement empêchaient encore les clients d’obtenir les meilleures informations possibles.

Un autre point douloureux – je suis un goulot d’étranglement

Alors, qu’est-ce qui empêchait traditionnellement d’obtenir les informations les plus précises sur les produits ? L’écrivain!

Le rédacteur technique est le seul contributeur de contenu qui se tient entre les experts techniques et les clients pour fournir des informations techniques que les clients peuvent utiliser de manière fiable et efficace. Certes, un produit sans rédacteurs techniques peut être difficile à utiliser, mais le temps et les efforts nécessaires à un rédacteur pour comprendre suffisamment bien les informations pour écrire constituent un autre goulot d’étranglement.

Agile Blog image 2

Étant donné que les rédacteurs techniques sont souvent les seuls à avoir accès aux fichiers source de la documentation publiée, toute contribution de correction, de réécriture ou de mise à jour doit être saisie et produite par eux dans son format final.

La prochaine révolution – Documents open source

L’open source donne à chacun un certain niveau d’accès aux fichiers source du produit. Dans le cas des documents Redis, cela signifie placer les fichiers source de notre documentation dans un référentiel accessible au public. N’importe qui peut afficher ces fichiers source et modifier une copie des fichiers pour suggérer des contributions, en changeant l’auteur du propriétaire du contenu en éditeur et conservateur de contenu. Vous pouvez même y accéder directement à partir du lien “Modifier sur GitHub” sur chaque page de nos documents.

Blog Agile Image 1

Ce simple changement de méthodologie ouvre la propriété de l’exactitude de la documentation aux experts techniques de Redis, ainsi qu’à nos clients et partenaires qui expérimentent le comportement du produit chaque jour. Ajoutez cela à la livraison immédiate des contributions approuvées à docs.redis.comet nous avons considérablement amélioré notre capacité à fournir une documentation actualisée et précise à nos clients.

Nous ne nous arrêtons pas maintenant

Bien sûr, ce n’est que le début des améliorations que nous apportons à notre documentation produit, mais nous pensons que ce changement sera la base de beaucoup de bonnes choses à venir.

Donc, si vous voulez contribuer à aider tout le monde à tirer le meilleur parti de la base de données la plus rapide au monde, n’hésitez pas : contribuez !

Development Source

Related Posts

RLEC 4.2.1 apporte des contrôles granulaires à la haute disponibilité et aux performances

RLEC 4.2.1 apporte des contrôles granulaires à la haute disponibilité et aux performances

Comment HolidayMe utilise Redis Enterprise comme base de données principale

Comment HolidayMe utilise Redis Enterprise comme base de données principale

Annonce de RedisGears 1.0 : un moteur sans serveur pour Redis

Annonce de RedisGears 1.0 : un moteur sans serveur pour Redis

Clés Redis dans la RAM |  Redis

Clés Redis dans la RAM | Redis

No Comment

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *