Wikify-fr

De Mi caja de notas

Révision datée du 22 février 2020 à 05:05 par Xtof (discussion | contributions)

Cette page a démarré sur iwc:wikifying et sera synchronisée pour traduction sur iwc:wikifying-fr

wikifying is the practice of capturing information and ideas on the wiki. E.g. "We need to wikify that FAQ, concept, jargon, or etherpad".

Follow the step by step directions on this page to:

  • Step 1: Create your wiki page.
  • Step 2: Edit your wiki page.
  • Step 3: (optional) add your self to chat-names
  • Step 4: (optional) create a sparkline so there is a picture next your chat-name

Then begin to contribute to the wiki.

Why Join the IndieWeb Wiki

As a community, we eschew email in lieu of real-time chat and documentation of the important points on the wiki to make it easier to search and build information and documentation over time.

When you join the wiki you help our community grow and also provide documentation of your journey. This helps the next person who, like you, wants to control their data in the place that they own.

Each person who joins the wiki has a user page they maintain and build over time. You can shape your page to tell your story. As you get started please consider these examples as you look for ideas.

IndieWeb Examples

How to Join the IndieWeb Wiki

Unlike other sites where you choose a username and password, you only need your domain name to log in to this wiki. It uses indielogin.com to authenticate you. If you have not done so already, set up web sign-in on your domain so you can be authenticated and log in.

In addition to being able to log into the wiki, this web sign-in should also allow you to log into and RSVP to events as well as to use many other IndieWeb building blocks like publishing apps and social readers.

Step One: Create your user page

After logging in, visit your user page. Then click Create. You can choose two templates to add a profile to your page.

  • Minimum Profile
  • Infobox Profile

If you want to edit your page at a later date go to your own user page (or click your domain name at the top right). From there, click Edit.

Minimum Profile

The IndieWeb community uses h-cards to identify people online. This is like a business card for your website.

The smallest h-card includes your name and a link to your website. 

<span class="h-card">[https://example.com/ Your Name]</span>

Infobox Profile

If you would like to include a profile box like Aaron Parecki for example, we have created a template for you.

Go to Infobox person and copy the entire template. Then return to the Edit tab of your user page (or click Create if there isn't already a page. Paste the template onto your user page. Replace/fill out the relevant data you'd like to display. You can use the Show Changes button at the bottom of the page to preview how things will look before you save them. Once things look the way you'd like them to save your changes. Remember you can always make changes later if you'd like to.

Avoid creating separate User pages

Your domain is your login when you sign in to the wiki, so your wiki "User:" page will also be your domain. This provides a profile page for your login and your wiki contributions are linked to it. Please do not create separate "User:" pages that are your name, nickname, etc.

When you (or anyone else) visit(s) your "User:" page, you will see a link in the sidebar (left or right depending on theme) to "User contributions", which you (or anyone) can click to see your recent contributions to the wiki.

Any separate "User:" pages are "fake" and don't have any login information associated with them so they lack such a "User contribution" link for you or anyone to check your contributions to the wiki.

If you do (whether accidentally or with good intentions) create a separate "User:" page, you can either delete it or redirect it to your actual "User:" page with your login domain.

If you mistakenly redirect your actual "User:" page to a separate "User:" page, you may need to "Move" any contents from your separate "User:" page to your actual "User:" page, overwriting that redirect.

If someone makes one of the above mistakes, please reach out to them on chat and alert them, linking them to this section to advise them on why and how to repair their "User:" page setup.

If they are not on chat, or don’t respond, it’s ok to make such repairs accordingly, and please leave a kind comment in any edit summaries, that link back to this section explaining why, and encourage joining chat for any follow-up questions.

Step Two: Edit Your Wiki page

You can shape your wiki page any way you like. There are some common elements many community members include:

Write down your itches

Main article: itches

Next, add an itches section where you capture what you want to work on for your own site, personal online digital presence, and personal digital device usage (e.g. even when offline) in general. E.g. 

== Itches ==
* Add a more extensive [[h-card]] on my site
* Figure out a [[URL design]] for my posts
* Start posting [[notes]] manually at [[permalinks]]
* Try checking my site in indiewebify.me
* Check out [[IndieMark]] for additional ideas of things to add to my site

When you start collecting lots of itches, you may want to start prioritizing them, especially by what you're currently working on. Start a "Working on" section for that: 

== Working On ==
* the next thing I'm working on for my site
* the next next thing I'm working on getting working on my site
* ... etc.


Focus

As this is the IndieWeb, and this is about your IndieWeb user page, it should be about answering this question, continuously:

  • What is the next thing you want to get working on your personal site?

This means for example that the following are better left out and pursued elsewhere - like on your own site!

  • A personal to do list (of other non-personal-site things) - your IndieWeb user page is about work on your personal site.
  • Asking others to do work for you. Note: requests for help with IndieWeb specific itches/projects are ok, but address them to everyone, not just individuals. This is about what you want to work on - not asking others to do work.
  • Trying to get silos to do things, in general or with specific accounts - instead, document individual silo issues on the specific silo wiki pages, and follow-up there. Your itches should be about your personal site, not silos.

Additional Templates

These pre-defined wiki templates that can be added to a user page:

Step Three: Add a chat name

Optionally add yourself to chat-names. This will show your photo by your name in the chat logs and link your name to your website. It will also allow our friendly chat bot Loqi to answer "who is [username]" with information from your wiki user page.

To add a chat name visit chat-names and use the provided template.

Step Four: Add a sparkline

The IndieWeb wiki allows sparklines, a small avatar that contains your photo and your name linked to your user page. This means people can add a text snippet like 

{{your-chat-name}}

to any page to display your name linked to your user page with an option avatar displayed next to it.

  • Example: {{chrisaldrich}} entered into a wiki page will display: Chris Aldrich.

Visit the template to add a sparkline.

Why Contribute to the IndieWeb Wiki

Wikifying both in general, and particular subjects, notes, or documents, helps grow the searchable & discoverable commons of the IndieWeb community.

Is it IndieWeb related? Great, add it to the wiki. Not sure? See examples of what (not) to add:

How to Contribute to the IndieWeb Wiki

Finding pages that need improvement

If you're looking for a way to help improve the wiki, consider looking for old pages and help clean them up and improve them! The sections below describe ways you can improve pages, such as fixing typos, ensuring pages have some sort of IndieWeb relevance, adding citations, or even deleting a page.

Here are some ideas for how to find pages that are likely to need improvement.

  • Pages with the Fewest Revisions - These are pages likely to have been defined in chat and need to be expanded. (You can ignore the "redirect pages" in this list.)
  • Short Pages - These pages have very little text. Sometimes that's because a redirect was created incorrectly, or sometimes the page was defined in chat and never expanded.
  • Oldest Pages - This is a list of pages sorted by the oldest date since the last edit. They are likely to have stale information, or may not meet our current standards for wiki pages if they were created many years ago.
  • Lonely Pages - These pages are not linked to by any other page. If the page is relatively complete itself, then consider adding links to it from relevant pages it may link to.

Incremental Wikifying

Main article: expand a page

There's lots of incremental wikifying to help with.

  • fixing typos
  • expanding (and/or simplifying) a definition to include the IndieWeb relevance of the term
  • rewriting a plumbing-centric definition to a user-centric definition and move any plumbing-specific meaning to a subsequent sentence or to another page (link to it and indicate "for developers" or some equivalent phrase)
  • adding IndieWeb Examples - if you find a page for a technology you support on your site, or a project you use on your site, add yourself to the "IndieWeb Examples" for that page
  • add issues and questions (for FAQs)
  • collect questions/answers from chat and add them to the appropriate wiki page
  • organize the content of a growing page into sections per expand a page

See:

  • expand a page for many more specific suggestions for incremental wikifying.
  • to-do for specific wiki pages that need incremental improvements!

In general, small incremental edits help with understandable diffs or differences that make wiki page updates easier for the community to review and help with corrections when necessary.

Add Citations

Whenever you see Loqi (or anyone frankly) share or post a link in chat to something relevant to the indieweb, please help out by adding those as citations/examples to the wiki, and especially if they're photos, add them to event page(s).

Format citations

Here's how to "text format" citations to add them, from a minimum, to incrementally doing more work (or improving existing citations!)

link
seriously, it's ok to just add a link, that's helpful!
YYYY-MM-DD link
adding the article's publication date helps a lot by placing the link in a temporal context
YYYY-MM-DD [link article-name]
even better, go get the article name which is likely more readable/understandable/searchable/discoverable than the link. Is it a tweet link or lacking a name? Pick a summary sentence instead.
YYYY-MM-DD author: [link article-name]
even better, add the author to help provide authority or at least the context of who-from
YYYY-MM-DD {{indiewebauthor}}: [link article-name]
even better, if the author is a participant in the indieweb community use the {{}} template for their shortname / chat nickname to link their name, perhaps even provide their icon automatically

Optionally:

  • Add a blockquote inline at the end of the citation, with key relevant sentence(s) copy/pasted/quoted from the link, like this:
YYYY-MM-DD [link article-name] <blockquote>key relevant sentence(s)!</blockquote>

These are all super-easy (nearly completely) plain-text ways of just pasting/typing the information into the wiki. (Nearly) No code or markup to learn or figure out or debug. Don't worry about not being perfect, others can help with tweaking fixing things.

Keeping wiki pages mostly plain-text-like makes them easier for others to edit and improve as well!

The important thing is to just take the step of adding the information.

If you like or are familiar MediaWiki templates, you can also use:

Where to add a citation

If you don't know where in a page to put a citation, add it to the See Also section at the end.

  • You can even do this from chat by using the << trick like this:
wikipagename << YYYY-MM-DD [link article-name]

etc.

If the citation is criticism, add/move it to the Criticism section of the article.

These are all incremental steps. None are required. All are something you can help with.

Every incremental step you can help with above helps the wiki.

Even just one incremental improvement is helpful!

New pages

Main article: start a page

Please read relevant to the IndieWeb wiki before creating new pages.

Create new wiki pages for:

  • new concepts or terms being discussed, e.g. in chat
    • start with {{stub}} and a short user-centric definition that includes its indieweb relevance! (see next section)
    • they should be directly indieweb-related in some way (this isn't Wikipedia)
    • if a term has a user-centric meaning and a plumbing-centric meaning, prefer the user-centric meaning for the definition on a wiki page
  • Archive pages for Etherpad notes from IndieWebCamp and HWC sessions after they’ve finished. Archive the session notes somewhere more findable and linkable.
  • new projects you start using on your personal website; be sure to include your site in the IndieWeb Examples section on the page.

If something is not particularly indieweb-related, e.g. it didn't come up in the discussion of things that are indieweb-related, perhaps consider documenting it on Wikipedia instead (and/or using Wikipedia as a reference/citation).

New pages that don’t immediately define their IndieWeb relevance may be deleted.

Multiword Page Names

When naming of multiword wiki pages, use multiple words with spaces, or dashes for multi-word terms., rather than WikiCase or camelCase.

Definitions include IndieWeb relevance

Definitions should include why something is specifically relevant to the IndieWeb.

E.g. the jargon example above could be improved with IndieWeb relevance like:

  • A jargon term is a specific unobvious word, concept, or technology (like Webmention), or re-use of a word to mean something other than its common meaning (like feed), or sometimes re-using a word as an acronym (like POSSE).

Please also avoid jargonitions, they’re much more harmful in practice than snarkinitions in terms of approachability. We’re ok with not necessarily attracting (or even perhaps detracting?) the Hackernews crowd, much more than scaring away non-developers. Humor at the expense of technology is much more acceptable than making people feel unwelcome with inaccessible text.

Document your decisions

Once you've documented yourself on your User page, and started incrementally documenting your "Itches" and "Working On", as you get work done and deploy to your personal site, document your "major decisions", on your user page or perhaps in a "Implementation Design" section on your project page.

Examples:

Documenting your major design and implementation decisions will help you better consider when to revisit them, and when to work on new personal site features and functionality instead.

Define jargon

Any time someone uses a jargon term in chat, or other indieweb related communications, go ahead and ask in the channel:

  • What is jargon term

This will prompt Loqi to either answer with the definition with the wiki, or to prompt you to define it with a link to create the page on the wiki.

You can then define it by clicking on that link, or answer answer the what is question:

  • A jargon term is a specific unobvious concept, or re-use of a word to mean something other than its common meaning.

See definition for more details on writing good definitions.

Tweetable definitions

Check the definitions on wiki pages, and edit them so they are tweetable, as there is evidence that people will tweet good definitions that are of tweetable length (including a subsequent link to the page) - that's 257 characters (space + 23 characters for the tco'd link).

Progressive disclosure of content

All pages should start with being the best source for basic knowledge on their subject.

Starting with a simple jargon-free Tweetable definition that is understandable by a broader audience, progressively document all the important research and details that are discovered or invented by the community about the subject.

And then incrementally document details only as needed for real world reasons / use-cases that provide benefits to those reading.

Nearly every page on the wiki can be improved in this regard, to provide progressive disclosure of relevant content.

E.g. getting started can (still) be continuously improved in this regard. As can web hosting.

Replacing Redirects

When editing a redirect (a page which is nothing more than a #redirect:[[]] line), if you are replacing it with actual content, first note in the #indieweb-meta discuss channel that you're going to replace it with actual content, then delete the redirect, and recreate the page with the new content.

Common Page Structure

Most pages on the wiki have evolved to have a fairly common page structure, starting with a simple definition, and then adding additional sections such as:

  • Why
  • How to
  • IndieWeb Examples
  • Brainstorming
  • See Also

For more details on these and more, see:

Special Case Pages

In addition to the common structure across many pages, there are also several clusters or instances of special case pages.

Standards Pages

The wiki has pages for standards / specifications that were developed on the indieweb wiki, and have started or been formalized at W3C, and thus their pages (and subpages) here have evolved in support of those specifications.

While these are rapidly evolving, take a look at:

There are also pages that are about the indieweb usage of standards developed elsewhere or in active collaboration across communities, e.g. the pages for various microformats. Though these are generally structured in the common structure noted above, they may as a set have special patterns worth noting:

(stub) - help expand this section with documentation of patterns across this type of special page.

Historical Pages

Some pages help document history, e.g.:

(stub) - help expand this section with documentation of patterns across this type of special page.

Cross-Generation Pages

As certain IndieWeb building-blocks become more widespread, folks from later generations could benefit from re-organized content. In some cases, it may be beneficial to break out "introductory" content (including high-level explanations, examples with screenshots, tools and services, ...) from "developer" content (such as protocol diagrams, code snippets, brainstorming, ...) For example:

(stub) - help expand this section with documentation of patterns across this type of special page.

General Suggestions

General suggestions for editing the wiki and adding prose.

In addition to incremental edits, consider the following:

Related Wikifying Articles

The above is very much specific to what is good wikifying for IndieWeb in particular.

Here are related articles on good writing, structure, and wikifying in general:

What not to contribute to the IndieWeb wiki

The list of things that have been added to the wiki or practices that are not particularly useful or appropriate for the IndieWeb wiki has grown enough for their own section.

Start by reading relevant to the IndieWeb wiki.

Do not copy from Wikipedia

Please do not copy text from Wikipedia, or even just restate the same thing as Wikipedia. Instead, link to the Wikipedia page, perhaps from the See Also section.

Do not copy from LLM generated text

Please do not use tools like ChatGPT to write text for the IndieWeb wiki, or otherwise copy text generated by a large language model (LLM).

Exception: if there is a good reason to do so (e.g. documenting a problem), you may quote (e.g. using <blockquote> tags) LLM output as long as it is clearly identified as such, preferably with a citation, and you have the right to quote it.

What not to add to See Also sections

Please do not add links to See Also sections of articles that are not directly IndieWeb related or from IndieWeb (personal) sites, or at least some sort of reasonably well established news source or topic-specific blog with original content, not summaries of content from other sites (link to original sources instead). Especially don't add links to sites/blogs that such summaries surrounded by ads. Such additions will likely be summarily reverted.

What not to add to headings

Avoid hyperlinks in headings

Do not put hyperlinks directly into (sub)headings, put them into the contents of that (sub)heading's section instead.

Why: linked headings by convention are typically linked to themselves as a shortcut for accessing a fragment permalink to that section, so when they link elsewhere (especially to another site) it’s a confusing user experience.

Avoid punctuation in headings

Avoid putting punctuation in headings, because they create ugly fragments for linking.

Instead remove such punctuation such as dashes, commas, or question marks (e.g. in FAQ subheadings), when putting something in a heading, and then put the longer version of such text including punctuation in the content immediately following the heading

FAQ

Should this be on the wiki

Do I have to use the wiki and MediaWiki syntax

While it's nice to put content into the wiki using standard markup for it, we realize not everyone is a wiki fan, knows how to do it, or even may have the time to learn to do it. (Documenting what you've done is both important and work enough.)

  • Alternative: Post on your own site with CC0! An alternate option is to practice the IndieWeb principle of posting on your own site first where you have ultimate control. Then webmention "Indieweb" (for Superfeedr) or dump the link into chat. As long as you license your content as CC0 for that post, someone will surely add it to the wiki on your behalf.
  • Add content, with double linebreaks for paragraphs! Users shouldn't feel guilty for adding content as best as they can (markup/formatting or not) where they feel it's appropriate. Others will come along and clean bits up in the near future. Nor should they hesitate to ask for help in chat if they'd like to learn more about wikifying.

Related chats:

Where should I add something to the wiki

When you see an IndieWeb related article, post, concept, and want to add it to the wiki, it may not be obvious where to add it, even just as a "See Also". Here are some tips for where to add something:

  1. An existing page it is most relevant to.
  2. If there are a couple of pages (e.g. maybe a general concept like privacy, and a specific silo like Facebook), it’s ok to add it to both.
  3. If you can think of a few different related pages, then create a new stub page for it, and then add a link to that stub page in the See Also sections of those related pages


See Also

  • start a page
  • expand a page
  • creator
  • commons
  • Template:sparkline#How_to_make_a_small_h-card_template
  • to-do
  • Possible thoughts for expanding this article in case of controversial edits or distribution: https://en.wikipedia.org/wiki/Talk:Recession#ATTENTION_NEW_VISITORS_TO_THIS_PAGE
  • Tip for use of < < — When you’ve found a tweet that you think would help add new relevant information to a page, if the tweet is primarily (or offhand) commentary about some other linked or screenshot resource, add that link instead, or go look for the original content in the screenshot and add that instead of the tweet.
  • ^ the [schmarty] rule
  • Help incorporate See Also additions into the core content & structure of a page. Go through See Also section list items that appear to have been added from chat via Loqi’s < < command, and figure out where they should go in the actual core content of the page. If you can't find an appropriate place, then expand a page with necessary sections accordingly.
  • General tip for incremental collaborative editing: when editing the wiki (or even one page), leave it in a similar (or better) "anyone else can still jump in and edit" state that you found it, rather than more of an "incomplete and no idea how to contribute" state, to keep the barrier low(er) for others to jump in and iterate on your edits, further incrementally improving the wiki (or that one page)
  • for pages about a technology, there should be near or at the top: a user-centric user flow/story diagram, and a very simple minimal code example, highlighting the specific tech in the context of its use (eg an mf2 class name highlighted inside an HTML element or two)
  • to-do actively discourage use of phrases like "simple to implement" that trivialize what is almost certainly not is trivial, thus only has the effect of making people feel bad when their implementation attempt or experience is not "simple".
  • to-do: actively discourage use of empty trivializing adverbs like "simply", "basically", "just", and please help copy edit pages that use those terms to trivialize suggested actions.
  • Please sign-in with your personal site, not your startup company's site, or your personal business site regardless of what the business is. User pages created for organizations, startups, or other businesses are likely to be deleted.
  • FAQ: Why is the page broken or empty after an HTML comment? A: look for an em-dash (—) as part of the HTML comment closer that may have been errantly added in a recent change, maybe by someone using the MediaWiki Visual Editor, and fix it by making sure all HTML comment tags use dash-dash (--) not any special dash (en-dash '–' or em-dash '—').
  • When in doubt whether to create a new page or not for something, start with documenting that something in a section on an existing page, until that section grows "enough" to seemingly be worth a separate page, and then create that separate page, move the content there, and leave behind a 2-3 sentence summary and a "main" template pointing to the new page.
  • per prior to-do re: "simply" "just" "basically" https://tantek.com/2021/087/t3/basically-just-simply-obscure
    • "Are there other words like:
      "basically"
      "just"
      "simply"
      used in explanations/instructions to obscure actual complexity or difficulty?

      Is there a name for such words?

      They often shame the reader as a side-effect (if it’s not easy, it must be my fault)" @Tantek Çelik March 28, 2021
  • ^ also: https://tantek.com/2021/087/t5/downplayer-word-make-something-less-significant
    • "Good additions @yoz.

      Starting from “trivializer” (see @toddbarnard thread), I found “downplayer”, and this fitting definition:

      “Downplayer: A word used to make someone or something look less significant.”
      — from https://www.deanza.edu/faculty/ramireztono/phil04/weekfiveoverhead.pdf

      Your examples “common X” and “standard Y” could be considered downplayer adjectives, except perhaps when in proper nouns like Common Lisp, Standard Oil, or if an actual standard (like HTML) is cited." @Tantek Çelik March 28, 2021
  • ^ another article/site on this topic: If someone’s having to read your docs, it’s not “simple”

    Scan your technical writing for words such as easy, painless, straightforward, trivial, simple and just. Chances are your writing will be clearer as a result of removing them.

wikifier désigne la pratique de poser des trucs sur le wiki, ou quelque chose de particulier sur le wiki. Par exemple, nous avons besoin de wikifier ces (FAQ|concept|jargon|etherpad).

Pourquoi

Wikifier en général, et notamment des sujets, des notes ou des documents, aide à développer les communs interrogeables et découvrables de la communauté IndieWebCamp.

Est-ce lié à l'IndieWeb ? Super, ajoute-le au wiki. Pas sûr ? Regarde des exemples de ce qu'il faut (ou ne pas) ajouter :

Comment faire

Se wikifier soi-même

Comme beaucoup de choses dans l'IndieWebCamp, commencez par éditer votre votre page, dans ce cas, votre propre page "User:".

Votre page "User:" est liée en haut et à droite au nom de votre domaine que vous avez utilisé pour vous connecter sur le wiki (juste avant "My talk" - ou "Page de discussion" si vous avez réglé vos préférences en français).

Cliquez dessus et éditer votre page User:.

Si vous n'êtes pas sûr quoi poser sur votre page User:, commencez simple. Nom, URL, h-card, par ex. 

<span class="h-card">[http://mondomaine.exemple.com/ Votre Nom]</span>

Puis, ajoutez une section "démangeaisons" ou "itches" où vous saisirez ce que vous voulez travailler sur votre propre site, une présence personnelle numérique en ligne, un usage numérique d'un terminal personnel (par ex. même quand vous n'êtes pas connecté). Par ex. : 

== Ce qui me démange ==
* Ajouter une [[h-card-fr|hcard]] complète sur mon site
* Imaginer un [[URL design-fr|design URL]] pour mes posts
* Commencer à poster manuellement des [[notes-fr|notes]] avec des [[permalinks-fr|permaliens]]
* Vérifier mon site avec indiewebify.me
* Mesurer mon [[IndieMark-fr|IndieMark]] pour quelques idées supplémentaires à ajouter sur mon site

Quand vous commencez à assembler beaucoup de démangeaisons, vous pourriez vouloir démarrer des priorités, tout spécialement en renseignant ce sur quoi vous travaillez en ce moment. Pour cela, démarrez par une section "Je bosse sur" : 

== En train de travailler ==
* la prochaine chose que je compte travailler sur mon site
* la prochaine prochaine chose que je travaillerai ....
* ... etc.


Pour finir, regardez les pages d'autres utilisateurs, tout spécialement les personnes qui ont fait ça depuis un moment, afin de voir ce que vous pourriez ajouter à votre page et travailler.

Concentration

Parce que c'est IndieWebCamp, et que ceci traite de votre page utilisateur IndieWebCamp, cela devrait revenir continuellement à vous poser la question :

  • Quelle est la prochaine chose que vous voulez travailler sur votre site personnel ?

Ce qui veut dire par exemple que les éléments suivants seront mieux à laisser de côté ou à poursuivre ailleurs - comme sur votre propre site !

  • Une todo liste personnelle (d'autres choses sur des sites non personnels) - votre page utilisateur IndieWebCamp est de travailler sur votre site personnel.
  • Demander aux autres de faire le travail pour vous. Note : les demandes d'aide pour les démangeaisons/projets spécifiques IndieWeb sont ok, mais adressez-les à tout le monde, pas seulement à des individus. Ceci concerne tout ce que vous voulez travailler - nous pas la délégation à d'autres du travail à réaliser.
  • Essayer de faire que les silos fassent des choses, en général ou avec des comptes spécifiques - au lieu de cela, documentez les problèmes de silos individuels sur les pages spécifiques des silos sur le wiki, et suivez-là. Vos démangeaisons devraient concerner votre site personnel, pas les silos.

Wikification Incrémentale

Article principal : expand a page-fr

Il y a beaucoup de wikification incrémentale à produire.

  • corriger les erreurs de typo
  • Ajouter des exemples IndieWeb - si vous trouvez une page pour une technologie que vous soutenez sur votre site, ou un projet que vous utilisez sur votre site, ajoutez-le vous-même à la section «Exemples IndieWeb" pour cette page
  • Ajoutez des problèmes et des questions (pour les FAQ)
  • Recueillez des questions/réponses de IRC et ajoutez-les à la page wiki appropriée
  • Organisez le contenu d'une page qui grandit en la découpant en sections agrandir une page


Nouvelles pages

Article principal : start a page-fr

Il y a beaucoup de création de nouvelles pages, que vous pouvez aider. Créer de nouvelles pages wiki pour :

  • de nouveaux concepts ou termes discutés, par exemple dans IRC
    • commencer par {{stub-fr}} et une courte définition !
    • surtout si elles sont en rapport avec indieweb d'une certaine façon
  • les etherpads des notes de sessions IndieWebCamp une fois terminées, pour archiver les notes de session dans un endroit plus trouvable/pointable.
  • les nouveaux projets que vous commencez à utiliser sur votre site personnel ; assurez-vous d'ajouter votre site dans la section Exemples IndieWeb sur la page.

Si quelque chose n'est pas lié à indieweb, par exemple ça n'a pas été soulevé dans la discussion comme des choses en rapport avec indieweb, envisagez peut-être de documenter sur Wikipedia à la place (et/ou en utilisant Wikipedia comme une référence/citation).

Documentez vos décisions

Une fois que vous avez vous-même documenté votre page d'utilisateur, et avez commencé à documenter de manière incrémentale vos "Démangeaisons" et "Le travail en cours", au fur et à mesure que vous effectuez le travail et le déploiement sur votre site personnel, documentez vos "grandes décisions" sur votre page d'utilisateur ou peut-être dans une section "Mise en œuvre de la conception" de votre page de projet.

Exemples :

Documenter vos grandes décisions de conception et de mise en œuvre vous aidera à mieux considérer quand les revoir, et quand travailler sur de nouvelles fonctionnalités et caractéristiques.

Définir le jargon

Chaque fois que quelqu'un utilise un terme de jargon sur IRC, ou d'autres canaux de communication indieweb, allez-y et demandez dans le canal :

  • What is terme jargon

Ceci alertera Loqi qui répondra soit avec la définition du wiki, ou vous alertera pour définir le terme avec un lien pour créer la page sur le wiki.

Vous pourrez ensuite définir le terme jargon en cliquant sur ce lien, ou répondre à la question :

  • Un terme jargon est un concept peu évident, ou une ré-utilisation d'un mot pour signifier quelque chose d'autre que son sens commun.

Essayez d'être spécifique et avec du sens dans les définitions, et ajoutez pourquoi c'est pertinent pour l'indieweb (si ce n'est pas évident à partir de la description).

Éviter de répéter les mots du terme, évitez les définitions abstraites génériques, et minimisez l'utilisation de termes du jargon dans une définition (utilisez-les si nécessaire, puis reliez/définissez les aussi).

définitions tweetables

Consultez les définitions sur les pages wiki, et modifiez-les pour qu'elles soient tweetables, car il est démontré que les gens tweeteront les bonnes définitions qui seront d'une longueur tweetable (en y ajoutant un lien à la suite de la page) - ce qui veut dire 116 caractères (espace + 23 caractères pour le lien raccourci tco).

Site deaths are when sites go offline, taking content and permalinks with them, and breaking the web accordingly. http://indiewebcamp.com/site-deaths

    • Notez qu'il a édité le dfn de site-deaths (à cette heure) et éliminé "their" afin de l'adapter à Twitter.

Divulgation progressive du contenu

Une définition tweetable (ou minimale) sans jargon simple est une première étape importante dans la fourniture d'un contenu qui soit compréhensible par un public plus large, tout en documentant toutes les recherches et les détails importants qui sont découverts ou inventés par la communauté.

Presque chaque page sur le wiki peut être améliorée à cet égard, afin de fournir une divulgation progressive du contenu pertinent..

Autrement dit, les pages wiki devraient commencer par offrir aux débutants des informations définitives et rapides.

Et ensuite documentez de manière incrémentale les détails si nécessaires pour le vrai monde et les cas d'utilisation qui fournissent des avantages aux lecteurs.

Par exemple Commencer peut (encore) être à cet égard continuellement améliorée. Comme on pourrait le faire avec l'hébergement web.

Articles en Rapport

Ce qui précède est très spécifique à ce qui est une bonne wikification pour IndieWebCamp, en particulier.

Voici les articles liés sur la bonne écriture, la structure et la wikification en général :

FAQ

Est-ce que cela devrait aller sur le wiki

Q : Avons-nous vraiment besoin de ça sur le wiki ?

R : Cela dépend ! En bref, tout ce qui concerne l'indieweb vaut la peine d'être posé sur le wiki, et bien sûr c'est à quelqu'un de prendre soin de le faire !

Voici quelques bons exemples de choses à mettre sur le wiki :

  • Tout sujet directement lié à l'IndieWeb, en particulier directement lié aux personnes dans la communauté avec leurs propres sites :
    • Technologies (par exemple Apache) les gens l'utilisent pour installer/construire/faire tourner/maintenir/surveiller leur site indieweb
    • Les services (par ex. l'hébergement web) que les gens utilisent pour leur site indieweb
    • Les événements ou podcasts qui discutent du web indépendant ou de l'IndieWeb en particulier, y compris les événements avec une seule conversation connexe (assurez-vous d'inscrire le discours spécifique)
    • Le Jargon représentant une technologie utilisée dans le cadre d'un site IndieWeb
    • Les silos qui ont l'art et l'antécédent (UX, design, formats, protocoles) pour les choses que nous voulons reconstruire indépendamment.

Qu'est ce qui ne devrait pas aller sur le wiki

Q: Si tout cela a du sens sur le wiki, qu'est-ce qui n'a pas de sens sur le wiki ?

R : Il y a tellement de choses qui ne nécessitent pas d'être sur le wiki qu'il est difficile de les énumérer toutes. De toute évidence, en dehors des choses comme les violations du code-de-conduite, voici quelques-unes que nous avons vu être ajoutées et décidé que ce serait mieux de les enlever. Ces choses semblent tomber dans le modèle-type de quand quelqu'un est passionné par quelque chose qui n'est pas lié à l'indieweb, et veut l'ajouter au wiki.

  • Les choses aléatoires. En général, les choses aléatoires qui ne disposent pas d'une connexion IndieWeb évidente sont mieux à déposer sur Wikipedia, et en utilisant les liens de Wikipedia plutôt que de créer des pages d'ébauches moins utiles sur le wiki IndieWeb. Par exemple.
    • Les termes techniques. Si un terme technique n'a pas de lien évident direct avec IndieWeb, pas besoin de le documenter ici.
    • Les organisations. Si une organisation n'a aucun rapport avec quoi que ce soit d'indépendant, elle peut probablement être laissée de côté.
      • Exception : Comme indiqué ci-dessus sous les silos, nous documentons tout/tous les sites/services que tout le monde a utilisé dans la communauté (ou même si des amis l'ont utilisé) qui ont annoncé ou sont menacés de fermeture, ou s'il a en particulier une UX qui vaut d'être capturée à des fins de recherche pour designer nos propres fonctionnalités indieweb.
    • événements. Si un événement n'a rien à voir avec l'indieweb, il n'a pas besoin d'être inscrit sur la page événements.


Discussion IRC en rapport :

Voir aussi

Récupérée de « https://ducamp.me/index.php?title=Wikify-fr&oldid=22224 »