Merge pull request #24 from decidim/milestone/launch

WIP: Milestone/launch - Landing Page

Author: basicavisual

_codebase/contributing.md

@@ -0,0 +1,7 @@
+---
+layout: page
+title: CONTRIBUTING.md
+description: A CONTRIBUTING file specifies what kinds of contributions is the project accepting, contribution etiquette, and guidance for people meaning to contribute to the project.
+---
+
+Contributing

_codebase/readme.md

@@ -0,0 +1,20 @@
+---
+layout: page
+description: A README file is a text file which introduces and explains the project¹. It is the first file any person looking at the code-base will see.
+---
+
+
+A README file is named as such, because it is intended to be the first file a person looks at when they see or download a piece of code. 
+
+When using a platform to publish your code on the internet, such as Github or Gitlab, if there's a file named "README" on the Root directory of your code-base, the platform will display that file on the front-page of the code, so that it will be the first thing anyone visiting your code-base will see. 
+
+You can build a README file by creating a file with a simple text editor (such as notepad, or gedit), name it README and choose an extension such as `.txt`. However, a good recommendation is to name it with the `.md` extension (to make it a [Markdown](https://www.markdownguide.org/) file). Markdown is recommended, because it is easy to use, and because most code-sharing platforms support an array of tools to enrich how your README looks like.
+
+### For begginers
+While there is no standard to what information should a README contain, Danny Guo's guide [**Make a readme**](https://www.makeareadme.com/#suggestions-for-a-good-readme) contains a very good start, as well as FAQ's about building good readmes, and a tool to build good starter READMEs. 
+
+### For intermediate users
+A good way to improve on a README is to look at other very good projects. Matias Singers has created a contributive and regularly up-to-date list of [Awesome Readmes](https://github.com/matiassingers/awesome-readme) anyone can get inspiration from. 
+
+## References
+¹ Guo, D. [https://github.com/dguo]. (n.d.). _Make a README_. Make a README. Retrieved January 19, 2025, from https://www.makeareadme.com/

_community/chats.md

@@ -0,0 +1,17 @@
+---
+layout: page
+---
+
+# About community chats
+
+A public, easily reachable, chat space where people can find others implementing the DPG. Different channels can be made for different types of profiles: i.e. a developers channel and an admin channel. On more advanced communities, people may have channels specialized in regions (i.e. Africa users) or interested in specific activities (i.e. policy building, or translation)"
+
+## How to implement 
+
+The first and most important aspect is tool selection. [AlternativeTo's updated compilation of Group Chats](https://alternativeto.net/category/social/group-chat/) page is a good place to start. While we are choosing not to recommend any single one option, we have compiled a guide to help you choose the right one for your community:
+
+  - Whether you self-host or use a service hosted by someone else. Open Source alternatives like Matrix.org and Rocket.Chat are good options for self-hosting. Matrix enables you to federate with other servers. Have in mind self-hosting requires allocating time for mantaining the service as well as a capable server. Options such as Telegram or Whatsapp are hosted freely, but keep in mind you won't own the data on it.  
+  - Choose an app that enables you to create different channels. This way you can have different spaces for different topics or profiles. This feature may be called different in different apps, such as "rooms" in Matrix or "channels" in Slack, "topics" in Telegram, etc.
+  - Make sure there's a system for people to easily be invited to the chat. Each application has its own sign-up workflow. For example, Telegram, Whatsapp and Slack have shareable links to join. Matrix has public chat links.
+
+Once you have chosen the proper tool, create an easily remberable link to the chat space. We recommend pointing directly from your website, something like chat.thenameofyourdomain.org or thenameofyourdomain.org/chat so that you can easily distribute it on presentations, and in-person gatherings. To do this, simply ask your IT administrator to point any of this links created by your to the corresponding link on your chosen app. You can see how this works by checking out how its done at Decidim on chat.decidim.org. 

_community/coc.md

@@ -0,0 +1,16 @@
+---
+layout: page
+description: A code of conduct is a document that establishes expectations for behavior for your project’s participants. Adopting, and enforcing, a code of conduct can help create a positive social atmosphere for your community.¹
+title: Code of Conduct
+---
+
+There are two parts to implementing a Code of Conduct (CoC) that you should consider:
+1. **Implementing one**: The text itself that will signal all of your contributors and participants to the project the range of Expected and Acceptable behaviours when contributing. The scope of the CoC (for example, the community spaces which it includes). And how will it be enforced, should any infringements happen: how can it be reported, what actions are expected to be taken, etc.
+2. **Enforcing one**: In the event that a person infringes the CoC, to have a procedure to enforce it that enables any decisions to be taken transparently, and the involved parties to understand the course of actions taken, and to document the steps to each case, so that the rest of the community has a means of transparency and accountability for actions taken. 
+
+A CoC can be established by including a file named `CODE_OF_CONDUCT.md` within the project repository, preferably at the root for easy finding. 
+
+
+## References
+
+¹ Your code of conduct. (2024, December 31). Open Source Guides. https://opensource.guide/code-of-conduct/

_community/repository.md

@@ -0,0 +1,34 @@
+---
+layout: page
+---
+
+# About the code repository
+
+Code for a DGP must be public and on a version control repository. A version control repository is a tool that takes the form of a website that's specialized in hosting code and provides collaboration tools for contributors users and code mantainers of the project to interact, examine the code, collaborate and contribute. Developers are well versed in the usage of this kind of tooling and should be able to set one up for your project.
+
+Here are some features of a Version control code repository: 
+
+
+1. Version Control: Tracking Changes & Preventing Loss
+
+Version control keeps a complete history of changes, allowing developers to revert to previous versions if needed. This prevents data loss and simplifies debugging. Branching enables developers to work on new features or fixes without affecting the main codebase until they are ready to merge.
+
+2. Collaboration: Enabling Contributions from Multiple Developers
+
+Multiple contributors can work simultaneously without overwriting each other’s changes. Branching and merging allow independent development and smooth integration, preventing conflicts and improving efficiency in distributed teams.
+
+3. Transparency & Accountability
+
+Every change is logged with details on who made it and why, ensuring a clear project history. This transparency enhances accountability and makes it easier to track progress, review past decisions, and manage contributions.
+
+4. Code Review & Quality Control
+
+Before merging, code is reviewed to ensure quality, identify bugs, and maintain standards. This process helps keep the project secure, efficient, and aligned with best practices while fostering learning among contributors.
+
+5. Issue Tracking & Documentation
+
+Repositories integrate issue tracking for reporting bugs, suggesting features, and planning updates. Built-in documentation ensures contributors understand the project, making collaboration smoother and more accessible.
+
+Platforms like [GitHub](https://github.com), [GitLab](https://gitlab.com), and [Bitbucket](https://bitbucket.org/) provide these features, making version control essential for open-source development, ensuring structured collaboration, and maintaining project quality over time.
+
+Options such as [GitLab](https://gitlab.com), [Forgejo](https://forgejo.org/) and [Gitea](https://about.gitea.com/) can be self-hosted, and some teams or organizations choose to have their version control code repository instances, however as any self-hosted solution, this requires dedicated team time and server resources to mantain your service.

_config.yml

@@ -24,7 +24,7 @@ description: >- # this means to ignore newlines until "baseurl:"
   Write an awesome description for your new site here. You can edit this
   line in _config.yml. It will appear in your document head meta (for
   Google search results) and in your feed.xml site description.
-baseurl: "/" # the subpath of your site, e.g. /blog
+#baseurl: "/" # the subpath of your site, e.g. /blog
 url: "" # the base hostname & protocol for your site, e.g. http://example.com
 twitter_username: jekyllrb
 github_username:  jekyll
@@ -41,6 +41,21 @@ collections:
   strategies:
     output: true
     permalink: /strategies/:slug/
+  codebase:
+    output: true
+    permalink: /guides/tech/codebase/:slug/
+  technology:
+    output: true
+    permalink: /guides/tech/technology/:slug/
+  community:
+    output: true
+    permalink: /guides/tech/community/:slug/
+  governance:
+    output: true
+    permalink: /guides/tech/governance/:slug/
+  technical_guide:
+    output: true
+    permalink: /guides/tech/:slug/
 
 # Exclude from processing.
 # The following items will not be processed, by default.

_data/how-to-decide.md

@@ -0,0 +1,28 @@
+
+
+
+### Build it or adapt it?
+
+You might have a need that requires your team to build new software. When should you build it from scratch and when should you adopt an existing solution? You may think: "but our needs are very specific." Or: "We want to ensure our software looks like the rest of the software we use (logos, colors, styles, branding), so we'd rather build it from scratch". To this, you might want to consider the following:
+
+1. Lots of governments, businesses, or organizations have similar processes, and there's probably a good, resilient, and constantly mantained solution that you could adopt out of the box. Do you need to have a software that enables citizens to have their own digital identities, and that they are compatible with citizen files and government procedures? How about [MOSIP](https://www.digitalpublicgoods.net/r/modular-open-source-identity-platform)? Do you want to track beneficiaries for social programmes and implement case management tools so case workers can follow-up on them? How about using [Aam Digital](https://www.digitalpublicgoods.net/r/aam-digital)? 
+
+You can check proven open source solutions for the public good by accessing the [Digital Public Goods Alliance Registry](https://www.digitalpublicgoods.net/), an iniative of the UN that recognizes well built, well mantained software, can be a public good serving millions. They have an extensive review process that ensure the software within the registry is of good quality.
+
+2. Most software nowadays is web software, and web software relies on 3 ubiquitous technologies that determine how any software looks on a web browser (think logos, colors, shapes of buttons, etc.): **HTML, CSS and Javascript**. These three languages are basic parts of any developer's toolbelt, and are independent of functionality. Good agnostic software will consider your branding needs a basic part of implementing it and good web developers should be able to modify a web application so that it uses your branding and looks like you built it from scratch. 
+
+
+### The hidden costs of building versus adopting
+
+You may want to have total control over the product you are building and don't want to deal with the learning curve of adopting a software that may well be complicated. Here's some reasons you should consider:
+
+1. Building from scratch is prone to missing important features. We take a lot of functionality for granted, which only comes from extensively using, testing and continously mantaining the same piece of software over the years. A lot of that functionality may be either invisible to end users or leave vulnerabilities open for hackers to discover. For example: An extensive log of all events that happen on the software is not visible to end users, but is crucial to diagnose errors in an application which is bound to happen. Imagine a piece of software serving an entire country and a part of it start to fails. You put your team to diagnose the issue but since event logging is not an end-user facing feature, it was never prioritised nor built. Now developers are left on the dark when trying to solve the issue. Using a piece of software that has a global community using it, means there is thousands of teams and organizations using and  testing it. Issues are detected and patched faster and new features get built.
+
+2. Software obsolescense is a thing. Most non-developers are thinking software is a one-time investment, where you build the software, install it and then are done with it. However any successful software needs to be continously mantained. From adding new features to patching edge-cases that were not considered in the initial version. 
+
+There's also an invisible risk in not updating a piece of software you run: All software is built to run on a specific version of a programming language and specific operating system tools, which they too are continously updated and mantained. Global teams mantaining these programming languages, libraries and operating systems track these updates by releasing new versions, and abandon or deprecate older versions which cease to receive updates. Once hackers find vulnerabilities in languages, libraries or operating systems, these teams patch the vulnerabilities only in their currently supported versions. If your team is not actually working to mantain the software you built by upgrading all of the languages, libraries and operating systems it depends on, it can become prone to attacks in a matter of a couple of years. You can protect yourself from this hassle by adopting an existing software solution that has continuous updates, so that you can benefit from security patches and new feartures.
+
+### Is this reusable?
+
+
+

_data/landing.yml

@@ -1,12 +1,12 @@
 hero: 
-  title: Open Source Toolkit for Public Administrations
-  subtitle: Implement a FLOSS strategy for the public sector
+  title: Digital Public Goods Toolkit for Public Administrations
+  subtitle: Implement DPGs into your policy for the public sector
   primary_button:
-    title: Build your policy
-    link: /#policy
+    title: Publish a DPG
+    link: /publish
   secondary_button:
-    title: Read the Decidim case
-    link: /decidim-case
+    title: Adopt DPGs
+    link: /adopt
 impact:
   title: FLOSS Govtech solutions can serve millions
   subtitle: "The Decidim project was built by one city, and has reached:"
@@ -26,6 +26,14 @@ policy:
     - title: How to re-use open-source projects ethically
       link: /re-using-open-source-projects
       image: unsplash-photo-2.jpg
+DGPs:
+  dpgs:
+    - title: What are DGPs and why work under this model
+      link: "#"
+    - title: Publish a DPGs
+      link:
+    - title: How to adopt a DPGs
+      link:
 faqs: Frequently asked questions for policy-makers
 resources:
   title: Browse our resources

_includes/footer.html

@@ -1,10 +1,10 @@
-<div class="container"></div>
-  <footer class="d-flex flex-wrap justify-content-between align-items-center py-3 my-4 border-top">
+<div class="border-top">
+  <footer class="container d-flex flex-wrap justify-content-between align-items-center py-3 my-4 ">
     <div class="col-md-4 d-flex align-items-center">
       <a href="/" class="mb-3 me-2 mb-md-0 text-muted text-decoration-none lh-1">
         <svg class="bi" width="30" height="24"><use xlink:href="#bootstrap"></use></svg>
       </a>
-      <span class="text-muted">© 2021 Company, Inc</span>
+      <span class="text-muted">{{site.title}}</span>
     </div>
 
     <ul class="nav col-md-4 justify-content-end list-unstyled d-flex">

_includes/header.html

@@ -5,7 +5,7 @@
     </a>
 
     <ul class="nav col-12 col-md-auto mb-2 justify-content-center mb-md-0">
-      <li><a href="{{ site.baseurl }}" class="nav-link px-2 link-secondary">Home</a></li>
+      <li><a href="{{ site.baseurl }}/" class="nav-link px-2 link-secondary">Home</a></li>
       <li><a href="{{ 'about' | relative_url }}" class="nav-link px-2 link-dark">About this project</a></li>
       <li><a href="https://decidim.org/" class="nav-link px-2 link-dark" target="_blank">Decidim</a></li>
     </ul>