D4.1 -- DREAM public collaborative website

DREAM WP4 - REPORTING
, ,
21

How do you think we should address these points?

22

I have some ideas. Will share later. Maybe in person first. :slight_smile:

1 Like
23

Some notes on the discussions on the website at the end of our week-long meetings:

  • Explain what is peer-to-peer from scratch? What are the points and uses of P2P (Preservation of data)?
  • Explain what group collaboration is in the sense of the DREAM project.
  • Explain “Open Knowledge” (in a tooltip definition?)
  • Change “We design networks and systems” to “We’re designing a system to…” to be less broad, more precise, and sound less like a corporation looking for work.
  • Display the timeline of the project deliverables on a page of the website.
  • “Organizing peer-to-peer” is not clear enough.
  • The website could use some definitions in tooltip of words
  • Write out “peer-to-peer” instead of “P2P”
  • “In 2021, we will research” could be a link to the timeline of deliverables.
  • Put the “NGI Pointer project” in a footnote, and use “An European research project” with a link to the footnote.
2 Likes
24

Yes, I get your point re: AsciiDoc(tor) vs Markdown. It should not be difficult to configure Nginx to serve an HTML generated from AsciiDoc instead of the Markdown file from the referenced URL. In this case, the ADOC files would end up in the dream.public.cat.git repository. We simply need to figure out a way to build them from source and output the wanted HTML at the right URLs. It should be straightforward. My plan last week was to include the nginx.conf anyway into this repository.

I propose that in the meantime you keep working on AsciiDoc documents until we set up a proper publishing workflow, and reference those files from the first post, so we can publish the links already – they will be indexed in search engine early, so that they’ll gain SEO over time. Once we have the final versions, we can simply switch to the HTML files (since nginx will serve static files in priority, skipping hitting the proxy for dynamic content).

Should we include the 6kly-cycles image in the web site somewhere?

1 Like
25

Deployment Script Fixed

#1 was fixed with this comment:

This was fixed in v0.3.1. The fetch command from the bare repository would not update the checkout , so I had to add the fetch refs to ensure proper update.

The only problem left is that updates to the dream-api.lua file are not automatically updated. Two steps need to be taken:

  1. copy the script from the checkout directory to /etc/nginx/scripts
  2. reload nginx.
1 Like
26

My screen is slightly unusual, and when I looked at the website, the left part was not visible (so part of the word design). When I make the screen even smaller, more things are not in the right place.

27

Yes @pukkamustard, there’s still no proper way to do it, but we can decide where it should go and stick to that.

For example, we could host the HTML docs under /doc/<project>/<package>, e.g., /doc/dmc/ocaml-dmc. BTW, should we stick to the Dromedar name or switch to DMC?

Then we can add the generated files to DREAM / dream.public.cat · GitLab (or better, have a Makefile that fetches the artifacts from Gitlab CI and add them to the repo. That can be a solution.

Note that in any way, /pub should be avoided (as /c, /t, etc.: whatever Discourse uses). Apart from this it’s fine. We should even put the nginx.conf in there so it’s picked up by the server – but if we do this, then we should as well move everything under etc/ and public/ for example to avoid having the server configuration in the web root.

1 Like
28

What size is your screen @arie?

29

I’m on a different screen now, but with 950 * 1350 (or ‘more square’ so decreasing the 1350),
it starts losing some text on the left.

30

Cool. No strong opinions on exact paths, I’d gladly leave it to your best judgement.

1 Like