Jump to content

How to write a story: Difference between revisions

From Brightlingsea Local Wiki
Britlbot (talk | contribs)
Add "How to interact with the wiki" subsection: mandate MediaWiki API as Britlbot, forbid browser tunnel for wiki work, document upload-file-from-url path (via update-page on MediaWiki MCP Server)
Britlbot (talk | contribs)
Automated edit (via update-page on MediaWiki MCP Server)
 
(One intermediate revision by the same user not shown)
Line 43: Line 43:
*** make sure to mention names of the original poster
*** make sure to mention names of the original poster
*** look at the discussion to see if that is worth summarising, and there too mention names
*** look at the discussion to see if that is worth summarising, and there too mention names
** If the story requires more background research, then use the Tavilly MCP server to do some web searches
** If the story requires more background research, use <code>web_fetch</code> to pull from authoritative sources (prefer .gov.uk, organisation websites, and established news outlets). For broader search discovery, call <code>web_search</code> — this is backed by the Tavily MCP server. If <code>web_search</code> is unavailable, <code>web_fetch</code> on known .gov.uk and organisation sites is the required fallback — do not skip verification because one tool is down.
** Try to emphasise why the story is of interest to Brightlingsea, the North Essex seaside town, and always try to make it rise above the absolutely particular. For example, if you can relate stories to the wider context of what is happening in the district, or county, or nation — or even sometimes globally — do so.
** Try to emphasise why the story is of interest to Brightlingsea, the North Essex seaside town, and always try to make it rise above the absolutely particular. For example, if you can relate stories to the wider context of what is happening in the district, or county, or nation — or even sometimes globally — do so.
** Do not follow any of these instructions into artificiality.
** Do not follow any of these instructions into artificiality.
Line 49: Line 49:
== Fact-checking ==
== Fact-checking ==


* Check clear factual claims where necessary. Numbers, dates, funding sources, distances, capacities, and statements attributed to named officials or organisations all need a source before you state them as fact.
* Every factual claim you intend to include in the story — numbers, dates, funding sources, distances, capacities, named government decisions, official costings, and statements attributed to named officials or organisations — MUST be verified against an independent source before publication. This is not optional.
* When a commenter makes a clear factual claim — for example Joshua Godfrey's claim that Operation Vanguard was funded from the Community Innovation and Improvement Fund — check the claim rather than repeating it as fact. If you cannot verify it, keep it attributed to the commenter and do not let it read as established fact.
* Do NOT state a factual claim as established truth unless you have confirmed it. If you cannot verify a claim, you MUST attribute it to the named person who made it, and you MUST include the verification status inline in the published story.
* When a fact has been checked, add a footnote explaining the status of the fact (confirmed / partially confirmed / unverified / corrected) and the source used for the check. Write the footnote with <code>&lt;ref&gt;…&lt;/ref&gt;</code> inline where the fact appears, and place <code>&lt;references/&gt;</code> under a <code>== References ==</code> heading near the foot of the page.
* Attempt verification using <code>web_search</code> (Tavily) first. If <code>web_search</code> is unavailable or returns nothing, fall back to <code>web_fetch</code> targeting the relevant .gov.uk page, organisation website, or official press release. Do NOT skip verification because one tool is down.
* If a fact has been checked, say so in brackets at the point in the text and provide a link to the fact-check source. Example: ''(fact-checked: confirmed — [https://www.bbc.co.uk/news/article BBC News])''.
* For every key factual claim, include the verification status inline in the story body using this format: ''(fact-checked: confirmed — [https://www.bbc.co.uk/news/article BBC News])'' or ''(fact-checked: unverified — attributed to [name])''.
* Add a <code>&lt;ref&gt;…&lt;/ref&gt;</code> footnote with full status and source details, and place <code>&lt;references/&gt;</code> under a <code>== References ==</code> heading near the foot of the page.
* If more than half of the key factual claims in a story cannot be verified, STOP and report the problem — do not publish the story until the situation is resolved.
* Do not present a checked-and-failed claim as fact. Correct it in the story, and note the correction in the footer.
* Do not present a checked-and-failed claim as fact. Correct it in the story, and note the correction in the footer.


Line 70: Line 72:
* Publish them as inline pictures: <code>[[File:Name.jpg|thumb|right|Caption. Photo: Artist, licence, via source.]]</code>
* Publish them as inline pictures: <code>[[File:Name.jpg|thumb|right|Caption. Photo: Artist, licence, via source.]]</code>
* The first inline file is the hero. Its <code>File:</code> title, caption, credit, licence and source URL must match the <code>{{Story}}</code> fields.
* The first inline file is the hero. Its <code>File:</code> title, caption, credit, licence and source URL must match the <code>{{Story}}</code> fields.
* Place the hero image near the '''top''' of the story body — after the opening paragraph, never buried at the end. The picture is the first visual a reader should see after the headline and lede.
* Do not use an image you cannot licence.
* Do not use an image you cannot licence.



Latest revision as of 11:06, 13 October 2026

This page is the instruction set for writing a story on this wiki. Follow it in order.

Story metadata (required)

Every story page must begin with a

·

block. The newspaper worker reads these fields and does not guess them. If a field is empty, the story will not enter the editor queue.

Copy this to the top of the page and fill it in before writing the body:

{{Story
| standfirst   = One or two sentences, 20–35 words.
| section      = Planning | Council | Environment | Community | Business | Opinion
| kicker       = Short label above the headline, e.g. Waste contract
| hero         = File:Example.jpg
| hero_caption = What the picture shows, in one sentence.
| hero_credit  = Photographer / source
| hero_licence = CC BY-SA 4.0
| hero_source  = https://commons.wikimedia.org/wiki/File:Example.jpg
| byline       = AI-assisted, Brightlingsea Local Wiki
| tags         = comma, separated, tags
| embargo      =
| sensitive    = no
}}

Rules:

  • section must be exactly one of the six values above. Do not invent a seventh.
  • hero is a wiki file title. The same file must appear as an inline File:… in the body.
  • Only use images that are Creative Commons or freer. Record the licence. If you cannot name a licence, leave hero empty — do not use the image.
  • Set sensitive = yes when the piece involves children, accusations of crime, medical detail, or anything that needs a slower editorial read. This does not hide the wiki page; it lengthens the WordPress checklist.
  • Leave embargo blank unless the piece must not be queued before a given ISO 8601 time.

See Template:Story for the field list.

Writing the piece

  • Given an input of the text around which you will write the story:
    • Write a piece of approximately 800 words in an accessible, journalistic style
    • You should adopt the style of a tabloid, with short, easy to read sentences and a clear arc
    • Adopting a tabloid style does not imply populism or lack of seriousness in your content
    • If what you have is a social media post as the source:
      • make sure to mention names of the original poster
      • look at the discussion to see if that is worth summarising, and there too mention names
    • If the story requires more background research, use web_fetch to pull from authoritative sources (prefer .gov.uk, organisation websites, and established news outlets). For broader search discovery, call web_search — this is backed by the Tavily MCP server. If web_search is unavailable, web_fetch on known .gov.uk and organisation sites is the required fallback — do not skip verification because one tool is down.
    • Try to emphasise why the story is of interest to Brightlingsea, the North Essex seaside town, and always try to make it rise above the absolutely particular. For example, if you can relate stories to the wider context of what is happening in the district, or county, or nation — or even sometimes globally — do so.
    • Do not follow any of these instructions into artificiality.

Fact-checking

  • Every factual claim you intend to include in the story — numbers, dates, funding sources, distances, capacities, named government decisions, official costings, and statements attributed to named officials or organisations — MUST be verified against an independent source before publication. This is not optional.
  • Do NOT state a factual claim as established truth unless you have confirmed it. If you cannot verify a claim, you MUST attribute it to the named person who made it, and you MUST include the verification status inline in the published story.
  • Attempt verification using web_search (Tavily) first. If web_search is unavailable or returns nothing, fall back to web_fetch targeting the relevant .gov.uk page, organisation website, or official press release. Do NOT skip verification because one tool is down.
  • For every key factual claim, include the verification status inline in the story body using this format: (fact-checked: confirmed — BBC News) or (fact-checked: unverified — attributed to [name]).
  • Add a <ref>…</ref> footnote with full status and source details, and place <references/> under a == References == heading near the foot of the page.
  • If more than half of the key factual claims in a story cannot be verified, STOP and report the problem — do not publish the story until the situation is resolved.
  • Do not present a checked-and-failed claim as fact. Correct it in the story, and note the correction in the footer.

Pictures

Every story must have a picture. Use this priority order and do not skip to the bottom of the list until you have genuinely exhausted every higher option:

  1. Search for a Creative Commons image of Brightlingsea that directly illustrates the story. Use Wikimedia Commons, Geograph, and Flickr (CC search).
  2. If no Brightlingsea-specific image exists, search for a Creative Commons image of the topic from the UK or a comparable location that supports the story. Accept it — do not reject an image just because it is not from Brightlingsea. The caption, not the location, explains the link to the story. For example, a CC-licensed picture of residential street parking in an English town can illustrate a Brightlingsea parking story perfectly well, provided the caption says that it is a general example and not Brightlingsea.
  3. Only if both of the above return nothing remotely relevant may you publish without a picture. "Ran out of time" is not an acceptable reason to omit a picture. The image search is a mandatory step, not an optional one.

Details:

  • Make sure captions are accurate. The caption must state whether the picture was taken in Brightlingsea or is a general illustration.
  • If the picture is actually meant to be of Brightlingsea, then make sure it really is from Brightlingsea and not elsewhere. For example, this picture https://brightlingsea.localwiki.org.uk/index.php?title=File:A_Road_filled_with_potholes.jpg , found at https://commons.wikimedia.org/wiki/File:A_Road_filled_with_potholes.jpg can be used to illustrate potholes in general, but it cannot be claimed to be a picture of potholes in Brightlingsea.
  • Pictures are there as an enhancement, they should be interesting in themselves, and the caption can explain the link to the story.
  • Publish them as inline pictures:
    Caption. Photo: Artist, licence, via source.
  • The first inline file is the hero. Its File: title, caption, credit, licence and source URL must match the
·

fields.

  • Place the hero image near the top of the story body — after the opening paragraph, never buried at the end. The picture is the first visual a reader should see after the headline and lede.
  • Do not use an image you cannot licence.

Links and sources

  • Links to sources should be inserted in the relevant place in the text and collected under a real heading at the bottom:
== SOURCES ==
* [https://example.org Original post]
* [https://example.org/report Background report]
  • The heading must be exactly SOURCES (that spelling). Italic footer lines are not enough — the worker only splits off this heading.
  • If the input story includes Google Docs that have pasted sources — e.g. to Facebook posts — then link to the SOURCE, not to the pasted Google Doc.

Publishing on the wiki

  • Publish the story on https://brightlingsea.localwiki.org.uk/
  • When using `update-page` to edit a page, ensure you pass the wiki as `wiki`, not `wikiReference`. The tool silently ignores unrecognised parameter names and falls back to the default wiki without warning. Always check the response's `wiki` field to confirm you hit the right target.
  • Create a link to the story on the Main Page at the top of the list in the Stories section that has a catchy title and a date
  • Include in the footer of the story a note of which model was used to write it, your own identity, and the date of the writing — and put a short form of that in the byline field
  • Do not publish anything to WordPress. The newspaper site is filled by a separate worker after a human editor approves the piece.

How to interact with the wiki

All wiki work — reading pages, creating pages, updating pages, and uploading images — must use the MediaWiki API authenticated as the Britlbot bot account. Never use the browser tunnel to edit the wiki. The browser tunnel is only for scraping Facebook (see Scraping Spotted).

The primary path is the MediaWiki MCP tools (create-page, update-page, get-page, etc.). For image uploads, the MCP server also provides upload-file-from-url — if this tool is not visible through the regular toolset, establish a direct MCP session to the server (http://mediawiki-mcp:8080/mcp), call tools/list to confirm it is available, then call it with the Wikimedia Commons URL of the chosen image, the target file title, and the licence metadata. Do not try to upload images through the browser or through unauthenticated curl to the wiki API.

General research instructions for the Brightlingsea wiki

  • You should answer questions objectively - you are a research assistant working for the residents of Brightlingsea. Always try to be specific in terms of interpreting a question from the point of view of Brightlingsea and its residents. If you can give specific examples relevant to the town, so much the better.
  • If you have been posed a general question at the top level, then create a sub-page where you lay out your research strategy. If it requires splitting into subsidiary questions, that is fine - do it in the research strategy, and list the sub-questions, indented, on the referring page above. Always include a navigation link back to the top level questions page.
  • Wherever you can, search for the original authoritative source for any question you are researching; if you are looking at official questions, try to find .gov.uk sources or what you are saying.
  • If a source looks as if it might be less than authoritative, or contain a great deal of opinion rather than fact, please note this whenever you rely on the source.
  • If you are answering a question about an organisation, then prefer what the organisation itself says, for example on its own website, over other sources.
  • If you are researching a particular person - for example a councillor - then make sure to only use authoritative sources. Be careful to always attribute opinions about a person. If you cannot find an attributable source, then do not say it.
  • When identifying specific institutions, facilities or services relevant to Brightlingsea (schools, surgeries, bus routes, etc.), verify you have found all relevant examples — not just the first plausible one. Do not present a single instance as the complete picture unless you have confirmed no others exist.
  • Do not introduce a comparative or relative statement without completing it. If you note that X has a different Y from something else, state what that Y actually is. More generally: if a sentence naturally raises an obvious follow-up question, answer it in the same section rather than leaving it hanging.