jekyll-theme-centos 2.2.0.beta.10 → 2.2.0.pre.staging.1

data/default.md

@@ -1,165 +0,0 @@
----
-title: "Nam euismod tellus id erat."
-title_lead: |
-  The Special Interest Groups (SIGs), are the teams responsible for their
-  specific CentOS Project variants. Variants are specialized and focused rebuilds
-  of CentOS to meet the needs and requirements of their corresponding communities
-  and the technology associated with those communities.
-layout: default
----
-
-SIGs are usually self-forming around a technology by a small community of
-enthusiasts and interested parties. In addition to the existing CentOS SIGs, it
-is expected that <code>additional SIGs</code>, as approved by the CentOS Board, will be
-created.
-
-<em>Praesent fermentum <code>tempor tellus</code>.  <strong>Nullam tempus.  Mauris ac <code>felis</code> vel velit tristique imperdiet.</strong>  Donec at pede.  Etiam vel neque nec dui dignissim bibendum.  Vivamus id enim.  Phasellus neque orci, porta a, aliquet quis, semper a, massa.  Phasellus purus.  Pellentesque tristique imperdiet tortor.  Nam euismod tellus id erat.  Nullam eu ante vel est convallis dignissim.  Fusce suscipit, wisi nec facilisis facilisis, est dui fermentum leo, quis tempor ligula erat quis odio.</em>
-
-```
-Each group will be responsible for its own variant in CentOS that is
-specifically targeted towards its community (e.g., The CentOS FooBar SIG
-creates a CentOS variant targeted to FooBar users and developers, the CentOS
-Hosting SIG builds a variant for web hosters, included in the CentOS
-distribution). The SIG is the deciding authority on what is required in their
-variant to satisfy the needs of their community, with the understanding that
-the Board has ultimate oversight as explained elsewhere. If required, the
-CentOS Board will help the individual SIGs to reach consensus on any issues or
-problems.
-```
-
-SIGs are the only way for an entity to use and associate the CentOS brand with
-a variant. You can always use Git and the repo to fork and try-out ideas, but
-only those packages in git.centos.org and released and signed by CentOS can be
-called 'CentOS'.
-
-Another type of SIG is functional, focused on maintaining parts of the Project
-itself, such as infrastructure, documentation, and design. A unique SIG is the
-Core SIG that builds and maintains the core CentOS derivative of Red Hat
-Enterprise Linux. It is unique because it is the central, orchestrating
-platform that all other variants are built from.
-
-# CentOS Core SIG Responsibilities
-
-* Build the CentOS release.
-* _Sign_ the CentOS release.
-* Push official CentOS releases to the initial mirror.
-* Coordinate with upstream as required.
-* Accept changes into Git.
-  * Manage Git licensing and contribution policies.
-
-## Level 2
-Fusce suscipit, wisi nec facilisis facilisis, est dui fermentum leo, quis tempor ligula erat quis odio.  Nunc porta vulputate tellus.  Nunc rutrum turpis sed pede.  Sed bibendum.  Aliquam posuere.  Nunc aliquet, augue nec adipiscing interdum, lacus tellus malesuada massa, quis varius mi purus non odio.  Pellentesque condimentum, magna ut suscipit hendrerit, ipsum augue ornare nulla, non luctus diam neque sit amet urna.  Curabitur vulputate vestibulum lorem.  Fusce sagittis, libero non molestie mollis, magna orci ultrices dolor, at vulputate neque nulla lacinia eros.  Sed id ligula quis est convallis tempor.  Curabitur lacinia pulvinar nibh.  Nam a sapien.
-### Level 3
-Fusce suscipit, wisi nec facilisis facilisis, est dui fermentum leo, quis tempor ligula erat quis odio.  Nunc porta vulputate tellus.  Nunc rutrum turpis sed pede.  Sed bibendum.  Aliquam posuere.  Nunc aliquet, augue nec adipiscing interdum, lacus tellus malesuada massa, quis varius mi purus non odio.  Pellentesque condimentum, magna ut suscipit hendrerit, ipsum augue ornare nulla, non luctus diam neque sit amet urna.  Curabitur vulputate vestibulum lorem.  Fusce sagittis, libero non molestie mollis, magna orci ultrices dolor, at vulputate neque nulla lacinia eros.  Sed id ligula quis est convallis tempor.  Curabitur lacinia pulvinar nibh.  Nam a sapien.
-#### Level 4
-Fusce suscipit, wisi nec facilisis facilisis, est dui fermentum leo, quis tempor ligula erat quis odio.  Nunc porta vulputate tellus.  Nunc rutrum turpis sed pede.  Sed bibendum.  Aliquam posuere.  Nunc aliquet, augue nec adipiscing interdum, lacus tellus malesuada massa, quis varius mi purus non odio.  Pellentesque condimentum, magna ut suscipit hendrerit, ipsum augue ornare nulla, non luctus diam neque sit amet urna.  Curabitur vulputate vestibulum lorem.  Fusce sagittis, libero non molestie mollis, magna orci ultrices dolor, at vulputate neque nulla lacinia eros.  Sed id ligula quis est convallis tempor.  Curabitur lacinia pulvinar nibh.  Nam a sapien.
-##### Level 5
-Fusce suscipit, wisi nec facilisis facilisis, est dui fermentum leo, quis tempor ligula erat quis odio.  Nunc porta vulputate tellus.  Nunc rutrum turpis sed pede.  Sed bibendum.  Aliquam posuere.  Nunc aliquet, augue nec adipiscing interdum, lacus tellus malesuada massa, quis varius mi purus non odio.  Pellentesque condimentum, magna ut suscipit hendrerit, ipsum augue ornare nulla, non luctus diam neque sit amet urna.  Curabitur vulputate vestibulum lorem.  Fusce sagittis, libero non molestie mollis, magna orci ultrices dolor, at vulputate neque nulla lacinia eros.  Sed id ligula quis est convallis tempor.  Curabitur lacinia pulvinar nibh.  Nam a sapien.
-###### Level 6
-Fusce suscipit, wisi nec facilisis facilisis, est dui fermentum leo, quis tempor ligula erat quis odio.  Nunc porta vulputate tellus.  Nunc rutrum turpis sed pede.  Sed bibendum.  Aliquam posuere.  Nunc aliquet, augue nec adipiscing interdum, lacus tellus malesuada massa, quis varius mi purus non odio.  Pellentesque condimentum, magna ut suscipit hendrerit, ipsum augue ornare nulla, non luctus diam neque sit amet urna.  Curabitur vulputate vestibulum lorem.  Fusce sagittis, libero non molestie mollis, magna orci ultrices dolor, at vulputate neque nulla lacinia eros.  Sed id ligula quis est convallis tempor.  Curabitur lacinia pulvinar nibh.  Nam a sapien.
-
-# Variant SIG Responsibilities
-
-* Create and maintain one or more variations with technology in CentOS on top of or modifications to the core base.
-* Foster a user community as a primary purpose of the variant.
-  * Keep the Project artifacts (the variant) relevant and useful to the user community.
-* Ensure the software brought in to support the variant is licensed and prepared properly for packaging and distribution as part of the CentOS Project.
-* Oversee inclusions of code related to the variant in to git.centos.org.
-* Conduct the business of the SIG following accepted open source practices around meritocracy and consensus decision making.
-
-# Functional SIG Responsibilities
-* Accountable for designing, building, and maintaining key Project component(s).
-* Make the functional area open for participation, with barriers to contribution as low as feasible and reasonable.
-* Foster a community of users and doers around the functional aspect, to share the responsibility, workload, and innovation.
-* Work within given legal constraints and requirements.
-
-# SIG Governance
-
-<figure class="figure">
-  <img class="figure-img img-fluid" src="/about/governance/sig-maturity-crossover.png" alt="SIG Governance">
-</figure>
-
-The SIGs themselves also have a merit path toward autonomy and accountability
-for Project aspects. The determination of merit level is reflected in the
-amount of oversight required by the Board and the SIGs ability to self-sign and
-release software builds. As merit increases, Board oversight goes down, with a
-transition spot in the middle where the SIG naturally obtains more autonomy,
-usually toward the end of the "Early" phase.
-
-__Sandboxes__ are the entry point for all proposed SIGs. To enter, there must
-be a Champion from or approved by the Board and a proposal (which indicates the
-reason for the SIG, the expected audience, initial team, risks, etc.) For a SIG
-to be created, there must be at least 3 +1 votes from the Board (NOT including
-the Champion) and zero (nil) -1 votes. When approved, the Champion becomes the
-formal Mentor of the Sandbox SIG.
-
-Sandboxes cannot make formal releases, but can create releases that allow
-people, developers, etc. to use, test, and play with the build. Sandboxes are
-also closely monitored by the Board to ensure that they are attracting interest
-and developers and users are learning the ropes regarding SIG operation. All
-new committers, developers, SIG core team members, etc. must be approved by the
-Board.
-
-SIGs that have expressed a level of merit, as determined by the Board, will
-move to the __Early__ SIG stage (Sandboxes can request graduation to Early, if
-they like). These SIGs are allowed to create formal releases, but the release
-must be approved by the Board and signed by the Mentor. In all other matters,
-however, they are self-sufficient and no longer require Board approval, such as
-as in adding committers and so forth. Movement from Sandbox to Early is via 3
-+1 vote of the Board (Mentor not included) and zero (nil) -1 votes.
-
-The final stage is the __Mature__ SIG. Again, this graduation is based on the
-judgment and determination of the Board, but this movement must be a unanimous
-decision of the Board. The Mature SIG has full control over the SIG, pulling in
-its own sources to git.centos.org, its releases, its internal governance, and
-has the ability to self-sign releases. The Board members may vote in, or
-participate in any SIG decision at any time.
-
-In both the Sandbox and Early SIGs, the role of the Board is primarily to
-facilitate the movement of those SIGs towards the Mature level; it serves as an
-initial gateway with the goal of getting out of the way of the SIGs.
-
-Note that in all cases, maturity is a measure of the community itself, and not
-the codebase or the actual SIG variant release. A mature SIG could create a
-non-mature (e.g., Alpha or Beta release) distribution and, conversely, a
-Sandbox SIG could produce a very mature (robust and reliable) distro.
-
-# Community and SIGs
-
-SIGs represent the true power and value of the CentOS Project. As seen in the
-current CentOS Dojos, and in the CentOS community itself, the builds provide a
-safe, neutral, and communal central meeting place for major technology areas.
-This is the reason why SIGs should not be program/project specific (e.g., a
-MariaDB rebuild), but rather technology-area focused (e.g., the "Hoster's"
-rebuild). By creating a central point where all projects and communities can
-interact, using the OS as the common foundation, upstream projects will be able
-to reach and interface with a much larger audience.
-
-It is expected that SIGs may propose significant forking of the base CentOS
-core, such as introducing a new Python version or Linux kernel. It is the job
-of the Board and CentOS Core SIG to oversee and approve any forks that are
-pulled back into Git, including to ensure that these forks are supportable.
-This support is best done by an active and engaged variant SIG. The Board or
-CentOS Core SIG can pull a variant from release if they reasonably believe the
-variant SIG is unable to support the variant. Another option is reassigning an
-active variant from a dead SIG to a willing living SIG. The Board is
-specifically not limited in what it can do to protect the quality of the CentOS
-mark where it comes to the content and quality of a variant.
-
-# Creating a new SIG
-
-The process of creating a new SIG involves two major components:
-community building and the administrative side.
-
-Bring your SIG proposal first to the centos-devel mailing list to find
-other like-minded people who wish to start the SIG with you. Also look
-around outside of the CentOS project for people who may want to
-distribute projects on CentOS
-
-Once you have a core group that wants to make this happen, open a ticket
-on the [board issue tracker](https://git.centos.org/centos/board/issues)
-with your proposed SIG, and someone there will walk you through the
-process.
-
-For the current list of active SIGs, refer to
-[http://wiki.centos.org/SpecialInterestGroup](http://wiki.centos.org/SpecialInterestGroup)

data/index.md

@@ -1,9 +0,0 @@
----
-# Feel free to add content and custom Front Matter to this file.
-# To modify the layout, see https://jekyllrb.com/docs/themes/#overriding-theme-defaults
-
-layout: home
-title: jekyll-theme-centos
-title_lead: Jekyll theme for CentOS project websites.
-
----

data/people.md

@@ -1,63 +0,0 @@
----
-layout: people
-
-username: username
-fullname: username
-about:
-  section:
-    icon: '<i class="fa-solid fa-fingerprint"></i>'
-    name: "About Me"
-    preamble: ""
-    highlight: false
-    visible: true
-  content:
-    - "..."
-projects:
-  section:
-    icon: '<i class="fa-solid fa-toolbox"></i>'
-    name: "Projects"
-    preamble: "Opensource projects I work on my free time."
-    highlight: true
-    visible: true
-  content:
-    - name: Project1
-      link: ...
-      description: ...
-    - name: Project2
-      link: ...
-      description: ...
-posts:
-  section:
-    icon: '<i class="fa-solid fa-newspaper"></i>'
-    name: Posts
-    preamble: "Random ideas about opensource and the projects I use to work on."
-    highlight: true
-    visible: true
-    limit: 5
-pubkeys:
-  section:
-    icon: '<i class="fa-solid fa-key"></i>'
-    name: "Public Keys"
-    preamble: "This is what you need to validate the identity of my signed messages, and grant me access to your servers."
-    highlight: true
-    visible: true
-  content:
-    - name: GPG
-      content: |
-        ...
-    - name: SSH
-      content: |
-        ...
-support:
-  section:
-    icon: '<i class="fa-solid fa-circle-dollar-to-slot"></i>'
-    name: Support
-    preamble: |
-      If you value my work and want to support me, you can buy me a cup of coffee ☕😎
-    highlight: false
-    visible: true
-  content:
-    - "--- Put your Liberapay code here. ---"
-
----
-