Editorial guide

These principles apply to how the wiki is developed and maintained.

Smart grid transitions cannot be fully understood from any one disciplinary perspective. For instance, while engineering as a field allows to focus on what is technically feasible, institutional analysis highlights how rules and incentives make certain options viable. Further, exploring the perspectives of various actors underlines their distinct visions, needs and practices. Each approach illuminates something the others might miss, and each does not provide a complete outlook on any given topic. One can therefore use triangulation of different perspectives to gain a better outlook on the realities of energy transitions.

Triangulation is a method from the social sciences for understanding real-world phenomena by combining multiple theoretical perspectives and methods. The aim is to compensate for the limitations of any single method and to strengthen the credibility of findings through convergence across different approaches. Using multiple perspectives in combination makes it possible to understand phenomena in a more differentiated way: to identify priorities based on a fuller picture, to spot where different framings are compatible and where they conflict, and to develop options that are robust and relevant from different viewpoints.

Every topic is explored from three perspectives. These are not separate sections to fill in independently; they are lenses that together give a fuller picture of how a smart grid concept operates in the real world. Where the perspectives interact, or where one uniquely exposes something the others miss, this should be made explicit in the text. The three perspectives also have some resemblance to how the wiki is structured, but this structuring works somewhat differently. While a topic might belong in the “Technologies & Infrastructure” category because of how it is commonly used, it still benefits from having three different perspectives filled out as other disciplines might have other interpretations.

Wiki development is a co-creative process. Every topic has a small team.

Lead authors are the core of the wiki and every topic needs one. Lead authors take responsibility for a topic from first draft to publication: organising input from co-authors, coordinating the review process, addressing comments, and keeping the topic current after it is published.

What is expected:

• Commitment to oversee the topic from the first draft to publication, including addressing reviewer comments and coordinating with the contributors
• Subject-matter expertise relevant to the topic, ideally covering more than one of the three ISGAN perspectives (actors, technology, institutions)
• Willingness to regularly update the topic based on feedback and new evidence

On diversity: Topic teams work best when lead authors and contributors bring diverse ISGAN perspectives and regions. If you are taking on a topic, consider who else might contribute from a different disciplinary or geographical angle.

To sign up as lead author: Contact the WG7 Task Lead or reach out via the contact page. If a topic already has a lead author listed on its page, contact them directly to discuss collaboration.

To propose a new topic: See the New topic guide.

The process has three stages and three decision gates. Gate 1 is a lead author self-check before external review begins. Gate 2 is the substantive quality threshold before endorsement.

Gate 1 checklist

Completed by the lead author before sharing the draft externally. No external sign-off required.

Milestone 1: Draft is ready for external review.

Gate 2 checklist

Confirmed by the lead author and WG7 Task Lead before the topic moves to Stage 3. Any comment marked critical must be addressed before the topic proceeds. If the lead author disagrees with a critical comment, the reasoning must be documented and the reviewer informed.

Milestone 2: Topic is ready for endorsement.

Gate 3 checklist

Confirmed by the lead author before submitting to the inter-WG meeting.

Milestone 3: Topic is ready for publication.

Each topic carries a status visible on the start page and on the topic page. The lead author is responsible for keeping it current. Only topics with status published, under-approval, in-review, or draft are counted as active topics.

Every topic page carries a version number. The version and status move together at defined triggers.

• Major version (e.g., 1.0 to 2.0): A change to the shared definition or core framing of the page. Requires returning to Stage 1 and a new inter-WG endorsement.
• Minor version (e.g., 1.0 to 1.1): An editorial improvement, updated case, added reference, or corrected phrasing. Can be made at any status without restarting the process.

Once a shared definition is endorsed, only the definition is locked. The rest of the page remains open to improvement as minor revisions at any time. If contributors believe the definition needs changing, that triggers a major revision and a new endorsement cycle.

Start at version 1.0 on first publication. Update the version number and the updated date in the page metadata on every change. Use the optional topic notes section to record what changed between versions.

Topics may be assigned sensitivity ratings, however how they should function is still to be decided. At the moment no sensitivity ratings are assigned.

Every topic page allows for comments from lead authors, contributors and reviewers within the main body of the text.

How it works:

Select any passage of text on a topic page and a comment button appears. Click it to open a compose panel. Your comment is anchored to the selected passage and visible to other logged-in users via highlight markers in the text. Comments can be replied to, resolved, and closed by the lead author or an admin. The toggle button near the top of each topic page switches comment markers on and off. This does not delete comments but only hides the highlights for a cleaner reading view.

Who can comment: Any logged-in wiki user once editor rights are granted. Comments are not visible to anonymous readers.

Who can resolve comments: The lead author and wiki admins. Resolving a comment marks it as addressed; it remains in the record but is no longer shown as open.

Examples of instances for using comments:

• Flag a specific claim that needs a source or stronger evidence
• Note a definition that may conflict with another topic
• Suggest a phrasing change
• Mark a passage for follow-up after a meeting

Topics should read as though written by a knowledgeable colleague explaining something clearly. It should be direct and precise, with focus on building shared understanding.

Language rules:

• Use UK English spelling throughout.
• Use plain language. If a technical term is necessary, define it on first use.
• Prefer active constructions: “Several countries have introduced regulatory

sandboxes” rather than “Regulatory sandboxes have been established.”

• Prefer can and could over should when describing possibilities.

The wiki describes what is done and what options exist. It does not prescribe

  what countries ought to do.
* Avoid hollow evaluative phrases: "a fundamental shift", "a critical enabler",
  "plays an increasingly important role." State what changed and why it matters.
* Avoid generic prose markers: "It is important to note that",
  "This section explores", "Moreover", "Furthermore."
* Avoid unnecessary introductions: "In an era of increasing complexity",
  "Given the rapidly evolving landscape."
* Vary sentence length for readability and flow; avoid overly long sentences.

Headings: All section headings use sentence case. Write “Why this matters”, not “Why This Matters”.

Every topic page follows the same structure. Sections must appear in this order.

For markup syntax and code examples for each section, see the Wiki markup reference.

AI tools may be used in wiki development when helpful, but their use is not required or expected. Where AI is used, it can help reorganise source material into the template structure, improve sentence flow, reformat references, or convert approved documents into DokuWiki markup.

Three responsibilities remain with people regardless of AI assistance:

1. Source verification is mandatory and must be done by a person. The lead author is responsible for confirming that every cited source exists and that the content matches the claim in the text.
2. Editorial responsibility stays with the lead author. Co-authors and reviewers who become aware that AI has substantially altered text must inform the lead author so the attribution record is accurate.
3. Recording AI use is required. All AI-assisted work is documented in the Topic notes section. These records stay in the document and the Teams folder; they are not published on the live wiki.