Code Monkey home page Code Monkey logo

hexatomic.github.io's Introduction

Build Status

Sources for the Hexatomic project documentation

The project documentation for Hexatomic is built with mdBook. mdBook is built in Rust.

Development

Development, i.e., additions and changes to the project documentation, are pushed to the src branch, i.e., the default branch. GitHub Actions automatically picks up the changes from this branch, makes the build, and pushes the product to the master branch, from where it is automatically rendered on hexatomic.github.io via the GitHub Pages functionality.

GitHub Pages looks for a repository in a GitHub organization called {organization}.github.io (e.g., hexatomic.github.io), and will try to render the files in the master branch of this repository.

Requirements

You do not need to install Rust in order to build the documentation. Instead, mdBook is provided in binaries served from the project's GitHub releases page.

In order to build, you need:

Setup

The documentation has been set up by running mdbook init --theme in the root directory of this repository. This created a skeleton mdBook installation as well as copied the theme files. In this version of the documentation, only the Handlebars template file index.hbs has been changed (you can compare it with the original file by running mdbook init --theme in another directory to create a vanilla setup of mdBook, and then diffing the two index.hbs files).

Build

To build the documentation, run mdbook build in the root of this repository. To serve the documentation locally, run mdbook serve in the root of this repository. Without customization, the documentation will be served at http://localhost:3000/.

Hosting

The documentation is hosted as a GitHub page on <hexatomic.github.io>.

The deployment is automated via GitHub Actions continuous integration, see the workflow file .github/workflows/deploy.yml.

Making changes

The structure of the documentation is configured in src/SUMMARY.md. Only files that are added to the structure there appear in the documentation.

To add new sections to the documentation, create a Markdown file called {name}.md in a reasonable place in the src directory.

Add a link to your file to src/SUMMARY.md to render it, either in the front or back matter (as a simple Markdown link [text](relative path)), or in the nested list of contents (as a Markdown list item - [text](relative path)).

Images & code style

If you want to use images, place them in the same directory as your Markdown file. Only files that are used globally should go in src/static/img/. This makes it easier and less verbose to reference files in the Markdown (instead of ![text](../../../static/img/img.png) you can simply use ![text](img.png)).

Markdown dialect

mdBook uses the CommonMark specification of Markdown, specifically in its Rust implementation pulldown-cmark.

This is a generic Markdown implementation which is feature-complete and also supports tables in the PHP Markdown Extra syntax.

Known bugs

Creating a PDF file of the documentation

PDFs, or single page HTML views, of the documentation can be created via the print button in the upper right corner of the documentation. The browser can be used to print to PDF.

License

The Hexatomic documentation is licensed under a Creative Commons Attribution-ShareAlike 4.0 International license CC-By-SA-4.0 badge.

Copyright (c) 2018ff. The Hexatomic project team

hexatomic.github.io's People

Contributors

bbunzeck avatar clachenmaier avatar sdruskat avatar thomaskrause avatar

Watchers

 avatar  avatar  avatar

hexatomic.github.io's Issues

Add evaluation of maintainer change

On the project website under a new menu item, please write up

1.2 Maintainability (@sdruskat & @thomaskrause) - @bbunzeck to create toc entry in SUMMARY.md without a link.
1.2.1 Case study: maintainer change (@bbunzeck)

Later we'll evaluate how the change went and will document it under

1.2.1 Evaluation of maintainer change documentation

Document the documentation style we use

We should decide on a documentation style we adhere to, more or less.

I suggest to use the Google dev docs style guide (went to a good workshop by Google technical writers at CollabW19). It's quite comprehensive, but makes a lot of sense to me.

I don't think we should enforce this, but suggest that maintainers and devs look at it and take hints (and seriously think about their style in writing docs).

Change UI

It is currently easy to confuse project and software docs. Changing to a different UI (at least colours, optionally template or other) would help resolving this.

Document development & review workflow

As per discussion with @thomaskrause on 2019-01-23, we'll follow the GitHub-PR workflow for both code and docs:

  • Work happens in a fork

  • Submit PR (piecemeal if necessary)

  • Require review

    • All changes require review from maintainer
    • Project docs require review from the other project members (including PIs)
    • User docs can require reviews from non-developers (PIs, external users, etc.)
    • Code reviews require reviews from other devs
  • Reviewers approve

  • PR is rebased (default) by maintainer (originator until maintainer model is up and running) to keep clean commit history (PR is merged only if rebasing isn't possible due to conflicts)

  • Document this in the project documentation

Implement documentation review

As the project docs are the central project document in terms of the final report, we should review what we add here.

TODO

  • Find a pragmatic workflow that creates as little overhead as possible (e.g., just use GitHub projects with Kanban + review)

Add dynamic progress tracking

E.g., a timeline/Gantt-ish thinkg with milestones so that visitors of hexatomic.github.io can track progress easily.

Add section on infrastructural choices

Larger parts of this can possibly be copied from the project proposal.

Concrete TODOs

Write down idea of periodic code reviews of already merged (low-risk) PRs

Problem

You always need two people for every even very small changes at the same time in the project. (i.e., our "one maintainer is enough" assumption doesn't hold).

Maintainer might want to fix maintenance issues (e.g. not running on newer Java version, security update in dependency) but if there is only one maintainer, who reviews it?

Solution 1 (changes in funding required)

Community of maintainers (paid as RSE team or open-sourcy)

or

"Stack Overflow for Code review" on-demand community of code reviewers

Solution 2 (for the current landscape of funding)

Small code changes/maintenance fixes/dependency updates are still a PR with full static code analysis and minimal requirements (e. g. test coverage, no new code smell detected by static code analysis --> all enforceable by tools like Sonarcloud).
Periodic (once a year, quarter?) reviews of all changed code since the last "clean state". Can be performed by the same author/maintainer (distance in time helps to see that as "someone other code").
The process of how to this this periodic review is part of the project documentation so anyone can perform it. It is also documented when the last review was, what has been reviewed (and what not?) and what issues have been found

This approach is inspired by the "Weekly performance triage" of the Rust compiler:

Additions to "footer"

  • Contact email
  • Link to GitHub org
  • Link to documentation sources
  • Remove copyright link?

Process for experimental maintainer change

  1. Do a release
  2. Change maintainer to @bbunzeck
    1. Record baseline & profile future maintainer, e.g. questionnaire about previous experiences (see #37 (comment)) โœ”๏ธ
  3. @bbunzeck to read maintenance documentation
  4. @sdruskat or @thomaskrause (or both) to continue work on Hexatomic with different accounts
  5. @bbunzeck to maintain & document:
    1. Maintain 1 PR with documentation changes
    2. Maintain 1 PR with code changes
    3. Record differences between external (new account) and internal (existing account) PRs
    4. Maintain 1-2 feature releases
    5. Maintain 1 hotfix release
  6. Reporting & change back maintainer to @sdruskat or @thomaskrause:
    1. Analyse notes & document issues/solutions
    2. Classify issues
    3. Analyse GitHub activity logs
    4. Prepare paper
  7. Fixing:
    1. Fix documentation from issues reported in 5.
  8. Change maintainer to @bbunzeck
    1. Document improvements (improvmenet through experience vs. improvement through documentation)
      1. Why were interventions necessary before a feature release could be made (metric = bad)
      2. Why were interventions necessary after a feature release was made? (metric = semi-bad)

Note: Any abnormal (i.e. not expected maintainer/contributor) interaction between @bbunzeck & @sdruskat or @thomaskrause is an intervention.

Define and document repository structure

Moved here from https://github.com/hexatomic/meetings/issues/1

Decisions (based on discussion during the 1st project meeting and following):

Decisions:

  1. All software-related documentation sources go into gh.com/hexatomic/hexatomic/docs folder: user docs, dev docs, maintainer docs
  2. All rendered documentation (user, dev, maintainer) are deployed to hexatomic.github.io/hexatomic/{minor-version}/{user|dev|maintainer}
  3. All project-related documentation goes into the h.gh.io repo, and succinct subfolders: project management, etc.
  4. All project-related artifacts, e.g., project management files, etc., go into the h.gh.io src branch.
  • Document this in maintainer documentation.
  • Document this in the project documentation as a design decision.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.