This is an automated email from the ASF dual-hosted git repository.
git-site-role pushed a commit to branch asf-site
in repository https://gitbox.apache.org/repos/asf/training.git
The following commit(s) were added to refs/heads/asf-site by this push:
new d602e1f Site checkin for project Training: Website
d602e1f is described below
commit d602e1fa7ce6844e90cac8726db0b803a6a3a93d
Author: jenkins <[email protected]>
AuthorDate: Tue Oct 14 08:19:19 2025 +0000
Site checkin for project Training: Website
---
.../apache/incubator/CommunityBuilding/index.html | 14 ++++++--------
presentations/apache/incubator/Governance/index.html | 10 +++++-----
.../apache/incubator/VotingAndConsensus/index.html | 16 ++++++++++------
presentations/apache/training/demo/index.html | 2 +-
4 files changed, 22 insertions(+), 20 deletions(-)
diff --git a/presentations/apache/incubator/CommunityBuilding/index.html
b/presentations/apache/incubator/CommunityBuilding/index.html
index 508ccb6..d0ab77a 100644
--- a/presentations/apache/incubator/CommunityBuilding/index.html
+++ b/presentations/apache/incubator/CommunityBuilding/index.html
@@ -451,14 +451,12 @@ Explain how patches are reviewed, how votes work, and
what the project values mo
A well-onboarded contributor quickly becomes a confident participant.</p></div>
<div class="paragraph"><p>Assign mentors or “buddies” to guide new
contributors through their first few PRs or mailing list discussions.
Encourage experienced contributors to mentor others in turn, this builds
continuity and community depth.</p></div></aside></div></section>
-<section id="_encouraging_meritocracy_and_growth"><h2>Encouraging Meritocracy
and Growth</h2><div class="slide-content"><div
class="ulist"><ul><li><p>Recognize sustained effort, not
status.</p></li><li><p>Nominate new committers and PPMC members openly and
transparently.</p></li><li><p>Avoid “in-crowds” or hidden
decision-making.</p></li><li><p>Encourage shared ownership and delegate trust,
empower others to lead.</p></li><li><p>Pair recognition with empowerment, trust
contributors with [...]
-<aside class="notes"><div class="paragraph"><p>Meritocracy is central to The
Apache Way, but it’s often misunderstood.
-At Apache, “meritocracy” means <strong>trust built through
contribution</strong>, not authority by seniority.
-Merit is demonstrated collaboration, not individual status.</p></div>
-<div class="paragraph"><p>A committer is not a privileged title, it’s a
recognition of responsibility.
-Nominate and vote for new committers or PPMC members openly on the private
list.
-Make sure everyone understands how merit is earned and shared.</p></div>
-<div class="paragraph"><p>Balance recognition of effort with opportunities to
grow. Invite contributors to help with releases, votes, or documentation
leadership.</p></div></aside></div></section>
+<section id="_building_trust_and_recognising_growth"><h2>Building Trust and
Recognising Growth</h2><div class="slide-content"><div
class="ulist"><ul><li><p>Recognize sustained effort and impact, not titles or
status.</p></li><li><p>Nominate new committers and PPMC members through open,
transparent discussions.</p></li><li><p>Avoid “in-crowds” or informal
hierarchies, ensure decisions are visible and fair.</p></li><li><p>Encourage
shared ownership: delegate trust, empower others to lead.< [...]
+<aside class="notes"><div class="paragraph"><p>Trust in Apache communities is
earned through consistent contribution and collaboration.
+Recognition (such as committership) reflects responsibility, not privilege or
rank.</p></div>
+<div class="paragraph"><p>When adding new committers or PPMC members, conduct
nominations and votes openly on the private list, ensuring everyone understands
the process.
+Highlight that trust is granted through demonstrated participation and care
for the community.</p></div>
+<div class="paragraph"><p>Aim to balance recognition with growth: when you
acknowledge someone’s contributions, also create space for them to learn, lead,
and mentor others.</p></div></aside></div></section>
<section id="_retaining_and_motivating_contributors"><h2>Retaining and
Motivating Contributors</h2><div class="slide-content"><div
class="ulist"><ul><li><p>Highlight achievements in release notes or blog
posts.</p></li><li><p>Delegate trust early, give contributors visible
roles.</p></li><li><p>Involve community members in planning
discussions.</p></li><li><p>Celebrate milestones.</p></li><li><p>Recognize
ongoing, behind-the-scenes contributions.</p></li></ul></div>
<aside class="notes"><div class="paragraph"><p>Retention keeps a community
vibrant.
Volunteers stay when they feel trusted, valued, and part of something
bigger.</p></div>
diff --git a/presentations/apache/incubator/Governance/index.html
b/presentations/apache/incubator/Governance/index.html
index 646869e..39a92c4 100644
--- a/presentations/apache/incubator/Governance/index.html
+++ b/presentations/apache/incubator/Governance/index.html
@@ -422,9 +422,9 @@ moving from mentor-guided decision-making to independent,
community-driven leade
<aside class="notes"><div class="paragraph"><p>Governance isn’t just about
policy, it’s about culture and daily habits.
Each podling develops its own rhythm, but all must show progress toward
ASF-style transparency and community-led decision-making.
This session explains what that looks like in practice and how mentors can
help guide the process.</p></div></aside></div></section>
-<section id="_core_principles_in_practice"><h2>Core Principles in
Practice</h2><div class="slide-content"><div
class="ulist"><ul><li><p><strong>Community over Code</strong> - Decisions made
through open consensus</p></li><li><p><strong>Meritocracy</strong> -
Responsibility grows with contribution and
trust</p></li><li><p><strong>Transparency</strong> - All decisions visible on
public mailing lists</p></li><li><p><strong>Independence</strong> - Project can
thrive beyond any one employer</ [...]
+<section id="_core_principles_in_practice"><h2>Core Principles in
Practice</h2><div class="slide-content"><div
class="ulist"><ul><li><p><strong>Community over Code</strong> - Decisions made
through open consensus.</p></li><li><p><strong>Trust through
Contribution</strong> - Responsibility grows with demonstrated participation
and collaboration.</p></li><li><p><strong>Transparency</strong> - All decisions
visible on public mailing lists.</p></li><li><p><strong>Independence</strong> -
Proj [...]
<aside class="notes"><div class="paragraph"><p>These four principles are the
foundation of ASF governance.
-They are interdependent: transparency enables meritocracy, meritocracy
strengthens independence, and community-driven decisions keep projects healthy
long term.
+They are interdependent: transparency builds trust, trust supports
independence, and community-driven decisions keep projects healthy long term.
Podlings are expected to practice and demonstrate all four before
graduation.</p></div></aside></div></section>
<section id="_decision_making_at_the_asf"><h2>Decision-Making at the
ASF</h2><div class="slide-content"><div
class="ulist"><ul><li><p><strong>Consensus</strong> - Discuss until broad
agreement is reached</p></li><li><p><strong>Lazy consensus</strong> - Silence
implies consent for routine actions</p></li><li><p><strong>[VOTE]
threads</strong> - Used for binding decisions (e.g., new committers,
releases)</p></li><li><p><strong>At least three +1s</strong> required for
release approval</p></ [...]
<aside class="notes"><div class="paragraph"><p>ASF decision-making focuses on
<strong>discussion first, voting second.</strong>
@@ -466,11 +466,11 @@ The final step, drafting and gaining consensus on a
graduation resolution, confi
They probe community resilience, independence, and fairness.
If any answer raises concerns, it’s an opportunity for mentoring and cultural
adjustment, not a failure.
Self-awareness and reflection are marks of a healthy ASF
community.</p></div></aside></div></section>
-<section id="_summary"><h2>Summary</h2><div class="slide-content"><div
class="ulist"><ul><li><p>ASF governance matures through
practice</p></li><li><p>Mentors guide, PPMC leads</p></li><li><p>Transparency
and inclusiveness are essential</p></li><li><p>Healthy podlings govern
themselves, <strong>the Apache Way</strong></p></li><li><p>Graduation isn’t a
checklist, it’s recognition that the community already operates as an ASF
project</p></li></ul></div>
+<section id="_summary"><h2>Summary</h2><div class="slide-content"><div
class="ulist"><ul><li><p>ASF governance matures through
practice.</p></li><li><p>Mentors guide, PPMC leads.</p></li><li><p>Transparency
and inclusiveness are essential.</p></li><li><p>Healthy podlings govern
themselves, <strong>the Apache Way</strong>.</p></li><li><p>Graduation isn’t a
checklist. It’s recognition that the community already operates as an ASF
project.</p></li></ul></div>
<aside class="notes"><div class="paragraph"><p>Wrap up by emphasizing that
governance is learned through doing, not documentation.
Mentors succeed when they become nearly unnecessary.
-Graduation happens when the PPMC already behaves like an ASF PMC,transparent,
meritocratic, and sustainable.
-That’s what makes the ASF model so
enduring.</p></div></aside></div></section></div></div><div class="footer"><div
class="left"></div><div class="right"></div></div><script
src="reveal.js-5.1.0/dist/reveal.js"></script><script>Array.prototype.slice.call(document.querySelectorAll('.slides
section')).forEach(function(slide) {
+Graduation happens when the PPMC already behaves like an ASF PMC, transparent,
trusted, and self-sustaining.
+That’s what defines a lasting and resilient Apache
community.</p></div></aside></div></section></div></div><div
class="footer"><div class="left"></div><div class="right"></div></div><script
src="reveal.js-5.1.0/dist/reveal.js"></script><script>Array.prototype.slice.call(document.querySelectorAll('.slides
section')).forEach(function(slide) {
if (slide.getAttribute('data-background-color')) return;
// user needs to explicitly say he wants CSS color to override otherwise we
might break custom css or theme (#226)
if (!(slide.classList.contains('canvas') ||
slide.classList.contains('background'))) return;
diff --git a/presentations/apache/incubator/VotingAndConsensus/index.html
b/presentations/apache/incubator/VotingAndConsensus/index.html
index fa5d943..0240391 100644
--- a/presentations/apache/incubator/VotingAndConsensus/index.html
+++ b/presentations/apache/incubator/VotingAndConsensus/index.html
@@ -424,7 +424,7 @@ Encourage participants to reflect on how their projects
make decisions and where
<aside class="notes"><div class="paragraph"><p>The ASF model is designed to
scale without hierarchy.
Reaching and documenting consensus allows communities to self-govern
effectively.
Consensus gives contributors a voice, prevents dominance by any one entity,
and builds trust in community decisions.</p></div></aside></div></section>
-<section id="_principles_of_consensus_building"><h2>Principles of Consensus
Building</h2><div class="slide-content"><div
class="ulist"><ul><li><p><strong>Community Over Code:</strong> decisions belong
to the community, not individuals or
companies.</p></li><li><p><strong>Meritocracy:</strong> every voice matters;
influence is earned through constructive
contribution.</p></li><li><p><strong>Transparency:</strong> decisions are made
publicly on the project mailing list.</p></li><li><p><str [...]
+<section id="_principles_of_consensus_building"><h2>Principles of Consensus
Building</h2><div class="slide-content"><div
class="ulist"><ul><li><p><strong>Community Over Code:</strong> decisions belong
to the community, not individuals or companies.</p></li><li><p><strong>Trust
Through Contribution:</strong> influence is earned by showing up, contributing,
and engaging respectfully.</p></li><li><p><strong>Transparency:</strong>
decisions are made publicly on the project mailing list.</p>< [...]
<aside class="notes"><div class="paragraph"><p>These principles reinforce each
other.
“Community Over Code” emphasizes sustainability, people and culture matter
more than technology.
Meritocracy is not about hierarchy, but about earned trust through
contribution.
@@ -433,21 +433,25 @@ Transparency and respect ensure that everyone can
understand decisions and feel
<aside class="notes"><div class="paragraph"><p>Votes are the
<strong>end</strong> of discussion, not the start.
Always begin with open dialogue: “What do people think?” rather than “Vote +1
or -1.”
Summarize differing views and document them so the reasoning behind decisions
is clear.</p></div></aside></div></section>
-<section><section id="_forms_of_consensus"><h2>Forms of Consensus</h2><div
class="slide-content"><div class="ulist"><ul><li><p>Lazy Consensus - default
for routine actions</p></li><li><p>Consensus After Discussion — used when
objections arise</p></li><li><p>Formal Votes - required for binding ASF
decisions</p></li></ul></div><aside class="notes"><div
class="paragraph"><p>Consensus takes different forms depending on how much
discussion or formality is required.
+<section id="_forms_of_consensus"><h2>Forms of Consensus</h2><div
class="slide-content"><div class="ulist"><ul><li><p>Lazy Consensus - default
for routine actions</p></li><li><p>Consensus After Discussion — used when
objections arise</p></li><li><p>Formal Votes - required for binding ASF
decisions</p></li></ul></div>
+<aside class="notes"><div class="paragraph"><p>Consensus takes different forms
depending on how much discussion or formality is required.
Not every decision needs a formal vote, in fact, most don’t.
-The three main types are lazy consensus, consensus after discussion, and
formal votes.</p></div></aside></div></section><section
id="_lazy_consensus"><h2>Lazy Consensus</h2><div class="slide-content"><div
class="ulist"><ul><li><p>The default ASF decision model.</p></li><li><p>A
proposal is posted; if no one objects within 72 hours, it’s
approved.</p></li><li><p>Works well for routine or low-risk actions like
website or documentation updates.</p></li><li><p>Encourages forward progress
wit [...]
+The three main types are lazy consensus, consensus after discussion, and
formal votes.</p></div></aside></div></section>
+<section id="_lazy_consensus"><h2>Lazy Consensus</h2><div
class="slide-content"><div class="ulist"><ul><li><p>The default ASF decision
model.</p></li><li><p>A proposal is posted; if no one objects within 72 hours,
it’s approved.</p></li><li><p>Works well for routine or low-risk actions like
website or documentation updates.</p></li><li><p>Encourages forward progress
without bureaucracy.</p></li></ul></div>
<div class="paragraph"><p><em>Example:</em>
“I’ll merge this pull request in 72 hours unless anyone objects.”</p></div>
<aside class="notes"><div class="paragraph"><p>Lazy consensus depends on trust
and engagement.
It works best when contributors actively follow the mailing list and feel
welcome to speak up.
-Silence from disengaged participants isn’t consensus, it’s apathy, which
mentors should watch for.</p></div></aside></div></section><section
id="_consensus_after_discussion"><h2>Consensus After Discussion</h2><div
class="slide-content"><div class="ulist"><ul><li><p>Used when objections
arise.</p></li><li><p>Discuss until all significant concerns are
addressed.</p></li><li><p>Aim for <strong>rough consensus</strong>, broad
agreement, even if not everyone fully agrees.</p></li><li><p>Summa [...]
+Silence from disengaged participants isn’t consensus, it’s apathy, which
mentors should watch for.</p></div></aside></div></section>
+<section id="_consensus_after_discussion"><h2>Consensus After
Discussion</h2><div class="slide-content"><div class="ulist"><ul><li><p>Used
when objections arise.</p></li><li><p>Discuss until all significant concerns
are addressed.</p></li><li><p>Aim for <strong>rough consensus</strong>, broad
agreement, even if not everyone fully agrees.</p></li><li><p>Summarize the
final outcome publicly.</p></li></ul></div>
<aside class="notes"><div class="paragraph"><p>“Rough consensus” means that
strong objections have been resolved, not that everyone must agree.
It’s about inclusion and progress, not unanimity.
-The key is active listening, understanding and adapting to valid concerns
until the community feels comfortable moving
forward.</p></div></aside></div></section><section
id="_formal_votes"><h2>Formal Votes</h2><div class="slide-content"><div
class="ulist"><ul><li><p>Used when ASF policy or legal requirements require a
clear decision.</p></li><li><p>Common examples:</p><div
class="ulist"><ul><li><p>Code releases</p></li><li><p>Adding committers or PPMC
members</p></li><li><p>Podling gradu [...]
+The key is active listening, understanding and adapting to valid concerns
until the community feels comfortable moving
forward.</p></div></aside></div></section>
+<section id="_formal_votes"><h2>Formal Votes</h2><div
class="slide-content"><div class="ulist"><ul><li><p>Used when ASF policy or
legal requirements require a clear decision.</p></li><li><p>Common
examples:</p><div class="ulist"><ul><li><p>Code releases</p></li><li><p>Adding
committers or PPMC members</p></li><li><p>Podling graduation
proposals</p></li></ul></div></li><li><p>Held on the correct list:</p><div
class="ulist"><ul><li><p><code>dev@</code> for community
matters</p></li><li><p> [...]
<aside class="notes"><div class="paragraph"><p>Formal votes ensure
traceability and legal oversight.
They are not about control but accountability, they demonstrate that ASF
policy has been followed.
A -1 vote signals a concern to address, not a personal rejection.
-If an issue emerges mid-vote, such as a missing NOTICE file, it’s fine to
withdraw and restart the vote after fixing
it.</p></div></aside></div></section></section>
+If an issue emerges mid-vote, such as a missing NOTICE file, it’s fine to
withdraw and restart the vote after fixing it.</p></div></aside></div></section>
<section id="_release_voting_in_the_incubator"><h2>Release Voting in the
Incubator</h2><div class="slide-content"><div
class="ulist"><ul><li><p>Two-stage process:</p><div class="ulist"><ul><li><p>1.
<strong>PPMC vote</strong> on <code>dev@</code> to confirm podling
consensus.</p></li><li><p>2. <strong>IPMC vote</strong> on
<code>general@</code> for ASF-level
approval.</p></li></ul></div></li><li><p>IPMC votes are binding; at least three
+1s required.</p></li><li><p>Mentors ensure both vo [...]
<aside class="notes"><div class="paragraph"><p>Release voting is often
misunderstood.
The first vote demonstrates that the podling community agrees the release is
ready.
diff --git a/presentations/apache/training/demo/index.html
b/presentations/apache/training/demo/index.html
index 36f3912..d8004d6 100644
--- a/presentations/apache/training/demo/index.html
+++ b/presentations/apache/training/demo/index.html
@@ -525,7 +525,7 @@ Neat huh?</p></div></aside></div></section>
192-223: data [colheight = 3]
}</pre></div></div></div></section><section id="meme-diagram"><h2>Meme
Diagram</h2><div class="slide-content"><div class="listingblock"><div
class="content"><pre>Failed to generate image: convert failed: convert: unable
to read font `Impact' @ warning/annotate.c/RenderType/949.
convert: unable to read font `Impact' @ error/annotate.c/RenderFreetype/1396.
-convert: no images defined `/tmp/meme20251012-1-o8iyge.png' @
error/convert.c/ConvertImageCommand/3229.</pre></div></div></div></section><section
id="entity-relation-diagram"><h2>Entity Relation Diagram</h2><div
class="slide-content"><div class="imageblock"><img src="images/erd-test.svg"
alt="erd test"></div>
+convert: no images defined `/tmp/meme20251014-1-1zyitn.png' @
error/convert.c/ConvertImageCommand/3229.</pre></div></div></div></section><section
id="entity-relation-diagram"><h2>Entity Relation Diagram</h2><div
class="slide-content"><div class="imageblock"><img src="images/erd-test.svg"
alt="erd test"></div>
<aside class="notes"></aside></div></section><section
id="mermaid-flowchart"><h2>Mermaid: Flowchart</h2><div
class="slide-content"><div class="listingblock"><div
class="content"><pre>Failed to generate image: mmdc failed:
Error: Failed to launch the browser process!
/root/.cache/puppeteer/chrome/linux-1108766/chrome-linux/chrome: error while
loading shared libraries: libnss3.so: cannot open shared object file: No such
file or directory
