Google Git
Sign in
apache / incubator-wayang-website / refs/heads/deploy / . / docs / community / contribute / index.html
blob: e3d76abd9bdb6aaee0e12acf16c4ec64b5c111e4 [file] [log] [blame]
<!doctype html>
<html lang="en" dir="ltr" class="docs-wrapper plugin-docs plugin-id-default docs-version-current docs-doc-page docs-doc-id-community/contribute" data-has-hydrated="false">
<head>
<meta charset="UTF-8">
<meta name="generator" content="Docusaurus v3.1.1">
<title data-rh="true">How to contribute | Apache Wayang (incubating)</title><meta data-rh="true" name="viewport" content="width=device-width,initial-scale=1"><meta data-rh="true" name="twitter:card" content="summary_large_image"><meta data-rh="true" property="og:url" content="https://wayang.apache.org/docs/community/contribute"><meta data-rh="true" property="og:locale" content="en"><meta data-rh="true" name="docusaurus_locale" content="en"><meta data-rh="true" name="docsearch:language" content="en"><meta data-rh="true" name="docusaurus_version" content="current"><meta data-rh="true" name="docusaurus_tag" content="docs-default-current"><meta data-rh="true" name="docsearch:version" content="current"><meta data-rh="true" name="docsearch:docusaurus_tag" content="docs-default-current"><meta data-rh="true" property="og:title" content="How to contribute | Apache Wayang (incubating)"><meta data-rh="true" name="description" content="This guide documents the best way to make various types of contribution to Apache Wayang, including what is required before submitting a code change."><meta data-rh="true" property="og:description" content="This guide documents the best way to make various types of contribution to Apache Wayang, including what is required before submitting a code change."><link data-rh="true" rel="icon" href="/img/wayang-logo.jpg"><link data-rh="true" rel="canonical" href="https://wayang.apache.org/docs/community/contribute"><link data-rh="true" rel="alternate" href="https://wayang.apache.org/docs/community/contribute" hreflang="en"><link data-rh="true" rel="alternate" href="https://wayang.apache.org/docs/community/contribute" hreflang="x-default"><link rel="alternate" type="application/rss+xml" href="/blog/rss.xml" title="Apache Wayang (incubating) RSS Feed">
<link rel="alternate" type="application/atom+xml" href="/blog/atom.xml" title="Apache Wayang (incubating) Atom Feed"><link rel="stylesheet" href="/assets/css/styles.af2ccd7c.css">
<script src="/assets/js/runtime~main.535cf072.js" defer="defer"></script>
<script src="/assets/js/main.4ad3c7a5.js" defer="defer"></script>
</head>
<body class="navigation-with-keyboard">
<script>!function(){function t(t){document.documentElement.setAttribute("data-theme",t)}var e=function(){try{return new URLSearchParams(window.location.search).get("docusaurus-theme")}catch(t){}}()||function(){try{return localStorage.getItem("theme")}catch(t){}}();t(null!==e?e:"light")}(),function(){try{const a=new URLSearchParams(window.location.search).entries();for(var[t,e]of a)if(t.startsWith("docusaurus-data-")){var n=t.replace("docusaurus-data-","data-");document.documentElement.setAttribute(n,e)}}catch(t){}}(),document.documentElement.setAttribute("data-announcement-bar-initially-dismissed",function(){try{return"true"===localStorage.getItem("docusaurus.announcement.dismiss")}catch(t){}return!1}())</script><div id="__docusaurus"><div role="region" aria-label="Skip to main content"><a class="skipToContent_fXgn" href="#__docusaurus_skipToContent_fallback">Skip to main content</a></div><div class="announcementBar_mb4j" style="background-color:#fafbfc;color:#091E42" role="banner"><div class="announcementBarPlaceholder_vyr4"></div><div class="content_knG7 announcementBarContent_xLdY">⭐️ If you like Apache Wayang, give it a star on <a target="_blank" href="https://github.com/apache/incubator-wayang">GitHub</a>! ⭐ </div><button type="button" aria-label="Close" class="clean-btn close closeButton_CVFx announcementBarClose_gvF7"><svg viewBox="0 0 15 15" width="14" height="14"><g stroke="currentColor" stroke-width="3.1"><path d="M.75.75l13.5 13.5M14.25.75L.75 14.25"></path></g></svg></button></div><nav aria-label="Main" class="navbar navbar--fixed-top"><div class="navbar__inner"><div class="navbar__items"><button aria-label="Toggle navigation bar" aria-expanded="false" class="navbar__toggle clean-btn" type="button"><svg width="30" height="30" viewBox="0 0 30 30" aria-hidden="true"><path stroke="currentColor" stroke-linecap="round" stroke-miterlimit="10" stroke-width="2" d="M4 7h22M4 15h22M4 23h22"></path></svg></button><a class="navbar__brand" href="/"><div class="navbar__logo"><img src="/img/wayang.png" alt="Wayang Logo" class="themedComponent_mlkZ themedComponent--light_NVdE"><img src="/img/wayang.png" alt="Wayang Logo" class="themedComponent_mlkZ themedComponent--dark_xIcU"></div><b class="navbar__title text--truncate"></b></a></div><div class="navbar__items navbar__items--right"><a class="navbar__item navbar__link" href="/docs/start/download">Download</a><a class="navbar__item navbar__link" href="/docs/introduction/about">About</a><a class="navbar__item navbar__link" href="/docs/guide/installation">Developers</a><div class="navbar__item dropdown dropdown--hoverable dropdown--right"><a href="#" aria-haspopup="true" aria-expanded="false" role="button" class="navbar__link">Community</a><ul class="dropdown__menu"><li><a class="dropdown__link" href="/blog/">Blog</a></li><li><a aria-current="page" class="dropdown__link dropdown__link--active" href="/docs/community/mailinglist">Project</a></li></ul></div><div class="navbar__item dropdown dropdown--hoverable dropdown--right"><a href="#" aria-haspopup="true" aria-expanded="false" role="button" class="navbar__link">ASF</a><ul class="dropdown__menu"><li><a href="https://www.apache.org/" target="_blank" rel="noopener noreferrer" class="dropdown__link">Foundation</a></li><li><a href="https://www.apache.org/licenses/" target="_blank" rel="noopener noreferrer" class="dropdown__link">License</a></li><li><a href="https://www.apache.org/events/current-event.html" target="_blank" rel="noopener noreferrer" class="dropdown__link">Events</a></li><li><a href="https://privacy.apache.org/policies/privacy-policy-public.html" target="_blank" rel="noopener noreferrer" class="dropdown__link">Privacy</a></li><li><a href="https://www.apache.org/security/" target="_blank" rel="noopener noreferrer" class="dropdown__link">Security</a></li><li><a href="https://www.apache.org/foundation/sponsorship.html" target="_blank" rel="noopener noreferrer" class="dropdown__link">Sponsorship</a></li><li><a href="https://www.apache.org/foundation/thanks.html" target="_blank" rel="noopener noreferrer" class="dropdown__link">Thanks</a></li><li><a href="https://www.apache.org/foundation/policies/conduct.html" target="_blank" rel="noopener noreferrer" class="dropdown__link">Code of Conduct</a></li></ul></div><a href="https://github.com/apache/incubator-wayang" target="_blank" rel="noopener noreferrer" class="navbar__item navbar__link header-github-link" aria-label="GitHub repository"></a><div class="toggle_vylO colorModeToggle_DEke"><button class="clean-btn toggleButton_gllP toggleButtonDisabled_aARS" type="button" disabled="" title="Switch between dark and light mode (currently light mode)" aria-label="Switch between dark and light mode (currently light mode)" aria-live="polite"><svg viewBox="0 0 24 24" width="24" height="24" class="lightToggleIcon_pyhR"><path fill="currentColor" d="M12,9c1.65,0,3,1.35,3,3s-1.35,3-3,3s-3-1.35-3-3S10.35,9,12,9 M12,7c-2.76,0-5,2.24-5,5s2.24,5,5,5s5-2.24,5-5 S14.76,7,12,7L12,7z M2,13l2,0c0.55,0,1-0.45,1-1s-0.45-1-1-1l-2,0c-0.55,0-1,0.45-1,1S1.45,13,2,13z M20,13l2,0c0.55,0,1-0.45,1-1 s-0.45-1-1-1l-2,0c-0.55,0-1,0.45-1,1S19.45,13,20,13z M11,2v2c0,0.55,0.45,1,1,1s1-0.45,1-1V2c0-0.55-0.45-1-1-1S11,1.45,11,2z M11,20v2c0,0.55,0.45,1,1,1s1-0.45,1-1v-2c0-0.55-0.45-1-1-1C11.45,19,11,19.45,11,20z M5.99,4.58c-0.39-0.39-1.03-0.39-1.41,0 c-0.39,0.39-0.39,1.03,0,1.41l1.06,1.06c0.39,0.39,1.03,0.39,1.41,0s0.39-1.03,0-1.41L5.99,4.58z M18.36,16.95 c-0.39-0.39-1.03-0.39-1.41,0c-0.39,0.39-0.39,1.03,0,1.41l1.06,1.06c0.39,0.39,1.03,0.39,1.41,0c0.39-0.39,0.39-1.03,0-1.41 L18.36,16.95z M19.42,5.99c0.39-0.39,0.39-1.03,0-1.41c-0.39-0.39-1.03-0.39-1.41,0l-1.06,1.06c-0.39,0.39-0.39,1.03,0,1.41 s1.03,0.39,1.41,0L19.42,5.99z M7.05,18.36c0.39-0.39,0.39-1.03,0-1.41c-0.39-0.39-1.03-0.39-1.41,0l-1.06,1.06 c-0.39,0.39-0.39,1.03,0,1.41s1.03,0.39,1.41,0L7.05,18.36z"></path></svg><svg viewBox="0 0 24 24" width="24" height="24" class="darkToggleIcon_wfgR"><path fill="currentColor" d="M9.37,5.51C9.19,6.15,9.1,6.82,9.1,7.5c0,4.08,3.32,7.4,7.4,7.4c0.68,0,1.35-0.09,1.99-0.27C17.45,17.19,14.93,19,12,19 c-3.86,0-7-3.14-7-7C5,9.07,6.81,6.55,9.37,5.51z M12,3c-4.97,0-9,4.03-9,9s4.03,9,9,9s9-4.03,9-9c0-0.46-0.04-0.92-0.1-1.36 c-0.98,1.37-2.58,2.26-4.4,2.26c-2.98,0-5.4-2.42-5.4-5.4c0-1.81,0.89-3.42,2.26-4.4C12.92,3.04,12.46,3,12,3L12,3z"></path></svg></button></div><div class="navbarSearchContainer_Bca1"><div class="navbar__search"><span aria-label="expand searchbar" role="button" class="search-icon" tabindex="0"></span><input id="search_input_react" type="search" placeholder="Loading..." aria-label="Search" class="navbar__search-input search-bar" disabled=""></div></div></div></div><div role="presentation" class="navbar-sidebar__backdrop"></div></nav><div id="__docusaurus_skipToContent_fallback" class="main-wrapper mainWrapper_z2l0"><div class="docsWrapper_hBAB"><button aria-label="Scroll back to top" class="clean-btn theme-back-to-top-button backToTopButton_sjWU" type="button"></button><div class="docRoot_UBD9"><aside class="theme-doc-sidebar-container docSidebarContainer_YfHR"><div class="sidebarViewport_aRkj"><div class="sidebar_njMd"><nav aria-label="Docs sidebar" class="menu thin-scrollbar menu_SIkG menuWithAnnouncementBar_GW3s"><ul class="theme-doc-sidebar-menu menu__list"><li class="theme-doc-sidebar-item-link theme-doc-sidebar-item-link-level-1 menu__list-item"><a class="menu__link" href="/docs/community/mailinglist">Mailinglists</a></li><li class="theme-doc-sidebar-item-link theme-doc-sidebar-item-link-level-1 menu__list-item"><a class="menu__link" href="/docs/community/repositories">Repositories</a></li><li class="theme-doc-sidebar-item-link theme-doc-sidebar-item-link-level-1 menu__list-item"><a class="menu__link" href="/docs/community/team">Team</a></li><li class="theme-doc-sidebar-item-link theme-doc-sidebar-item-link-level-1 menu__list-item"><a class="menu__link" href="/docs/community/committer">Becoming a committer</a></li><li class="theme-doc-sidebar-item-link theme-doc-sidebar-item-link-level-1 menu__list-item"><a class="menu__link menu__link--active" aria-current="page" href="/docs/community/contribute">How to contribute</a></li><li class="theme-doc-sidebar-item-link theme-doc-sidebar-item-link-level-1 menu__list-item"><a class="menu__link" href="/docs/community/release">How to make a release</a></li><li class="theme-doc-sidebar-item-link theme-doc-sidebar-item-link-level-1 menu__list-item"><a class="menu__link" href="/docs/community/maturity">Maturity Model</a></li><li class="theme-doc-sidebar-item-link theme-doc-sidebar-item-link-level-1 menu__list-item"><a class="menu__link" href="/docs/community/security">Wayang Security</a></li></ul></nav></div></div></aside><main class="docMainContainer_TBSr"><div class="container padding-top--md padding-bottom--lg"><div class="row"><div class="col docItemCol_VOVn"><div class="docItemContainer_Djhp"><article><nav class="theme-doc-breadcrumbs breadcrumbsContainer_Z_bl" aria-label="Breadcrumbs"><ul class="breadcrumbs" itemscope="" itemtype="https://schema.org/BreadcrumbList"><li class="breadcrumbs__item"><a aria-label="Home page" class="breadcrumbs__link" href="/"><svg viewBox="0 0 24 24" class="breadcrumbHomeIcon_YNFT"><path d="M10 19v-5h4v5c0 .55.45 1 1 1h3c.55 0 1-.45 1-1v-7h1.7c.46 0 .68-.57.33-.87L12.67 3.6c-.38-.34-.96-.34-1.34 0l-8.36 7.53c-.34.3-.13.87.33.87H5v7c0 .55.45 1 1 1h3c.55 0 1-.45 1-1z" fill="currentColor"></path></svg></a></li><li itemscope="" itemprop="itemListElement" itemtype="https://schema.org/ListItem" class="breadcrumbs__item breadcrumbs__item--active"><span class="breadcrumbs__link" itemprop="name">How to contribute</span><meta itemprop="position" content="1"></li></ul></nav><div class="tocCollapsible_ETCw theme-doc-toc-mobile tocMobile_ITEo"><button type="button" class="clean-btn tocCollapsibleButton_TO0P">On this page</button></div><div class="theme-doc-markdown markdown"><header><h1>How to contribute</h1></header><p>This guide documents the best way to make various types of contribution to Apache Wayang, including what is required before submitting a code change.</p>
<p>Contributing to Wayang doesn’t just mean writing code. Helping new users on the mailing list, testing releases, and improving documentation are also welcome. In fact, proposing significant code changes usually requires first gaining experience and credibility within the community by helping in other ways. This is also a guide to becoming an effective contributor.</p>
<p>So, this guide organizes contributions in order that they should probably be considered by new contributors who intend to get involved long-term. Build some track record of helping others, rather than just open pull requests.</p>
<h3 class="anchor anchorWithStickyNavbar_LWe7" id="contributing-by-helping-other-users">Contributing by helping other users<a href="#contributing-by-helping-other-users" class="hash-link" aria-label="Direct link to Contributing by helping other users" title="Direct link to Contributing by helping other users">​</a></h3>
<p>A great way to contribute to Wayang is to help answer user questions on the user@ mailing list or on StackOverflow. There are always many new Wayang users; taking a few minutes to help answer a question is a very valuable community service.</p>
<p>Contributors should subscribe to this list and follow it in order to keep up to date on what’s happening in Wayang. Answering questions is an excellent and visible way to help the community, which also demonstrates your expertise.</p>
<p>See the <a href="/docs/community/mailinglist">Mailing Lists</a> guide for guidelines about how to effectively participate in discussions on the mailing list, as well as forums like StackOverflow.</p>
<h3 class="anchor anchorWithStickyNavbar_LWe7" id="contributing-by-testing-releases">Contributing by testing releases<a href="#contributing-by-testing-releases" class="hash-link" aria-label="Direct link to Contributing by testing releases" title="Direct link to Contributing by testing releases">​</a></h3>
<p>Wayang’s release process is community-oriented, and members of the community can vote on new releases on the dev@ mailing list. Wayang users are invited to subscribe to this list to receive announcements, and test their workloads on newer release and provide feedback on any performance or correctness issues found in the newer release.</p>
<h2 class="anchor anchorWithStickyNavbar_LWe7" id="contributing-by-reviewing-changes">Contributing by reviewing changes<a href="#contributing-by-reviewing-changes" class="hash-link" aria-label="Direct link to Contributing by reviewing changes" title="Direct link to Contributing by reviewing changes">​</a></h2>
<p>Changes to Wayang source code are proposed, reviewed and committed via GitHub pull requests (described later). Anyone can view and comment on active changes here. Reviewing others’ changes is a good way to learn how the change process works and gain exposure to activity in various parts of the code. You can help by reviewing the changes and asking questions or pointing out issues – as simple as typos or small issues of style.</p>
<h2 class="anchor anchorWithStickyNavbar_LWe7" id="contributing-documentation-changes">Contributing documentation changes<a href="#contributing-documentation-changes" class="hash-link" aria-label="Direct link to Contributing documentation changes" title="Direct link to Contributing documentation changes">​</a></h2>
<p>To propose a change to release documentation (that is, docs that appear under <a href="/docs/guide/getting-started">Developer</a> section), fork the website repo and edit the Markdown source files in Wayang’s docs/ directory, the README file shows how to build the documentation locally to test your changes. The process to propose a doc change is otherwise the same as the process for proposing code changes below.</p>
<p>To propose a change to the rest of the documentation (that is, docs that do <strong>not</strong> appear under <a href="/docs/guide/getting-started">Developer</a> section), similarly, edit the Markdown in the wayang-website repository and open a pull request.</p>
<h2 class="anchor anchorWithStickyNavbar_LWe7" id="contributing-user-libraries-to-wayang">Contributing user libraries to Wayang<a href="#contributing-user-libraries-to-wayang" class="hash-link" aria-label="Direct link to Contributing user libraries to Wayang" title="Direct link to Contributing user libraries to Wayang">​</a></h2>
<p>Just as Java and Scala applications can access a huge selection of libraries and utilities, none of which are part of Java or Scala themselves, Wayang aims to support a rich ecosystem of libraries. Many new useful utilities or features belong outside of Spark rather than in the core. For example: query optimizer code and language support probably has to be a part of core Wayang, but, useful machine learning algorithms can happily exist outside of Wayang.</p>
<p>To that end, large and independent new functionality is often rejected for inclusion in Wayang itself, but, can and should be hosted as a separate project and repository, and included in the wayang-packages.org collection.</p>
<h2 class="anchor anchorWithStickyNavbar_LWe7" id="contributing-bug-reports">Contributing bug reports<a href="#contributing-bug-reports" class="hash-link" aria-label="Direct link to Contributing bug reports" title="Direct link to Contributing bug reports">​</a></h2>
<p>Ideally, bug reports are accompanied by a proposed code change to fix the bug. This isn’t always possible, as those who discover a bug may not have the experience to fix it. A bug may be reported by creating a <a href="https://issues.apache.org/jira/projects/WAYANG/issues/WAYANG-16?filter=allopenissues" target="_blank" rel="noopener noreferrer">JIRA</a> or a <a href="https://github.com/apache/incubator-wayang/issues" target="_blank" rel="noopener noreferrer">GitHub Issue</a> but without creating a pull request (see below).</p>
<p>Bug reports are only useful however if they include enough information to understand, isolate and ideally reproduce the bug. Simply encountering an error does not mean a bug should be reported; as below, search JIRA and search and inquire on the Wayang user / dev mailing lists first. Unreproducible bugs, or simple error reports, may be closed.</p>
<p>It’s very helpful if the bug report has a description about how the bug was introduced, by which commit, so that reviewers can easily understand the bug. It also helps committers to decide how far the bug fix should be backported, when the pull request is merged. The pull request to fix the bug should narrow down the problem to the root cause.</p>
<p>Performance regression is also one kind of bug. The pull request to fix a performance regression must provide a benchmark to prove the problem is indeed fixed.</p>
<p>Note that, data correctness/data loss bugs are very serious. Make sure the corresponding bug report JIRA ticket is labeled as correctness or data-loss. If the bug report doesn’t get enough attention, please send an email to dev@, to draw more attentions.</p>
<p>It is possible to propose new features as well. These are generally not helpful unless accompanied by detail, such as a design document and/or code change. Large new contributions should consider wayang-packages.org first (see above), or be discussed on the mailing list first. Feature requests may be rejected, or closed after a long period of inactivity.</p>
<h3 class="anchor anchorWithStickyNavbar_LWe7" id="contributing-to-jira-maintenance">Contributing to JIRA maintenance<a href="#contributing-to-jira-maintenance" class="hash-link" aria-label="Direct link to Contributing to JIRA maintenance" title="Direct link to Contributing to JIRA maintenance">​</a></h3>
<p>Given the volume of issues raised in the Apache Wayang JIRA, inevitably some issues are duplicates, or become obsolete and eventually fixed otherwise, or can’t be reproduced, or could benefit from more detail, and so on. It’s useful to help identify these issues and resolve them, either by advancing the discussion or even resolving the JIRA. Most contributors are able to directly resolve JIRAs. Use judgment in determining whether you are quite confident the issue should be resolved, although changes can be easily undone. If in doubt, just leave a comment on the JIRA.</p>
<p>When resolving JIRAs, observe a few useful conventions:</p>
<ul>
<li>
<p>Resolve as Fixed if there’s a change you can point to that resolved the issue</p>
<ul>
<li>Set Fix Version(s), if and only if the resolution is Fixed</li>
<li>Set Assignee to the person who most contributed to the resolution, which is usually the person who opened the PR that resolved the issue.</li>
<li>In case several people contributed, prefer to assign to the more ‘junior’, non-committer contributor</li>
</ul>
</li>
<li>
<p>For issues that can’t be reproduced against master as reported, resolve as Cannot Reproduce</p>
<ul>
<li>Fixed is reasonable too, if it’s clear what other previous pull request resolved it. Link to it.</li>
<li>If the issue is the same as or a subset of another issue, resolved as Duplicate</li>
<li>Make sure to link to the JIRA it duplicates</li>
<li>Prefer to resolve the issue that has less activity or discussion as the duplicate</li>
</ul>
</li>
<li>
<p>If the issue seems clearly obsolete and applies to issues or components that have changed radically since it was opened, resolve as Not a Problem</p>
</li>
<li>
<p>If the issue doesn’t make sense – not actionable, for example, a non-Spark issue, resolve as Invalid</p>
</li>
<li>
<p>If it’s a coherent issue, but there is a clear indication that there is not support or interest in acting on it, then resolve as Won’t Fix</p>
</li>
</ul>
<p>Sometimes, a contributor will already have a particular new change or bug in mind. If seeking ideas, consult the list of starter tasks in JIRA, or ask the user@ mailing list.</p>
<p>Before proceeding, contributors should evaluate if the proposed change is likely to be relevant, new and actionable:</p>
<ol>
<li>Is it clear that code must change? Proposing a JIRA and pull request is appropriate only when a clear problem or change has been identified. If simply having trouble using Spark, use the mailing lists first, rather than consider filing a JIRA or proposing a change. When in doubt, email user@ first about the possible change</li>
<li>Search the user@ and dev@ mailing list archives for related discussions. Often, the problem has been discussed before, with a resolution that doesn’t require a code change, or recording what kinds of changes will not be accepted as a resolution.</li>
<li>Search JIRA for existing issues: <a href="https://issues.apache.org/jira/browse/WAYANG" target="_blank" rel="noopener noreferrer">https://issues.apache.org/jira/browse/WAYANG</a></li>
<li>Is the scope of the change matched to the contributor’s level of experience? Anyone is qualified to suggest a typo fix, but refactoring core scheduling logic requires much more understanding of Wayang. Some changes require building up experience first (see above).</li>
<li>It’s worth reemphasizing that changes to the core of Wayang, or to highly complex and important modules like SQL and Catalyst, are more difficult to make correctly. They will be subjected to more scrutiny, and held to a higher standard of review than changes to less critical code.</li>
</ol>
<h3 class="anchor anchorWithStickyNavbar_LWe7" id="ml4all-and-optimizer-specific-contribution-guidelines">ML4ALL and optimizer-specific contribution guidelines<a href="#ml4all-and-optimizer-specific-contribution-guidelines" class="hash-link" aria-label="Direct link to ML4ALL and optimizer-specific contribution guidelines" title="Direct link to ML4ALL and optimizer-specific contribution guidelines">​</a></h3>
<p>While a rich set of algorithms is an important goal for Wayang, scaling the project requires that maintainability, consistency, and code quality come first. New algorithms should:</p>
<ol>
<li>Be used and accepted (academic citations and concrete use cases can help justify this)</li>
<li>Be well documented</li>
<li>Have APIs consistent with other algorithms in Wayang</li>
<li>Come with a reasonable expectation of developer support</li>
<li>Error message guidelines</li>
<li>Exceptions thrown in Wayang should be associated with standardized and actionable error messages</li>
</ol>
<h4 class="anchor anchorWithStickyNavbar_LWe7" id="error-messages-should-answer-the-following-questions">Error messages should answer the following questions:<a href="#error-messages-should-answer-the-following-questions" class="hash-link" aria-label="Direct link to Error messages should answer the following questions:" title="Direct link to Error messages should answer the following questions:">​</a></h4>
<ul>
<li>What was the problem?</li>
<li>Why did the problem happen?</li>
<li>How can the problem be solved?</li>
</ul>
<p><strong>When writing error messages, you should</strong>:</p>
<ol>
<li>Use active voice</li>
<li>Avoid time-based statements, such as promises of future support</li>
<li>Use the present tense to describe the error and provide suggestions</li>
<li>Provide concrete examples if the resolution is unclear</li>
<li>Avoid sounding accusatory, judgmental, or insulting</li>
<li>Be direct</li>
<li>Do not use programming jargon in user-facing errors
8 See the error message guidelines for more details.</li>
</ol>
<h3 class="anchor anchorWithStickyNavbar_LWe7" id="code-review-criteria">Code review criteria<a href="#code-review-criteria" class="hash-link" aria-label="Direct link to Code review criteria" title="Direct link to Code review criteria">​</a></h3>
<p>Before considering how to contribute code, it’s useful to understand how code is reviewed, and why changes may be rejected. See the detailed guide for code reviewers from Google’s Engineering Practices documentation. Simply put, changes that have many or large positives, and few negative effects or risks, are much more likely to be merged, and merged quickly. Risky and less valuable changes are very unlikely to be merged, and may be rejected outright rather than receive iterations of review.</p>
<h4 class="anchor anchorWithStickyNavbar_LWe7" id="positives">Positives<a href="#positives" class="hash-link" aria-label="Direct link to Positives" title="Direct link to Positives">​</a></h4>
<ul>
<li>Fixes the root cause of a bug in existing functionality</li>
<li>Adds functionality or fixes a problem needed by a large number of users</li>
<li>Simple, targeted</li>
<li>Maintains or improves consistency across Python, Java, Scala</li>
<li>Easily tested; has tests</li>
<li>Reduces complexity and lines of code</li>
<li>Change has already been discussed and is known to committers</li>
</ul>
<h4 class="anchor anchorWithStickyNavbar_LWe7" id="negatives-risks">Negatives, risks<a href="#negatives-risks" class="hash-link" aria-label="Direct link to Negatives, risks" title="Direct link to Negatives, risks">​</a></h4>
<ul>
<li>Band-aids a symptom of a bug only</li>
<li>Introduces complex new functionality, especially an API that needs to be supported</li>
<li>Adds complexity that only helps a niche use case</li>
<li>Adds user-space functionality that does not need to be maintained in Wayang, but could be hosted externally and indexed by wayang-packages.org</li>
<li>Changes a public API or semantics (rarely allowed)</li>
<li>Adds large dependencies</li>
<li>Changes versions of existing dependencies</li>
<li>Adds a large amount of code</li>
<li>Makes lots of modifications in one “big bang” change</li>
</ul>
<h3 class="anchor anchorWithStickyNavbar_LWe7" id="contributing-code-changes">Contributing code changes<a href="#contributing-code-changes" class="hash-link" aria-label="Direct link to Contributing code changes" title="Direct link to Contributing code changes">​</a></h3>
<p>Please review the preceding section before proposing a code change. This section documents how to do so.</p>
<p><strong>When you contribute code, you affirm that the contribution is your original work and that you license the work to the project under the project’s open source license. Whether or not you state this explicitly, by submitting any copyrighted material via pull request, email, or other means you agree to license the material under the project’s open source license and warrant that you have the legal authority to do so.</strong></p>
<h3 class="anchor anchorWithStickyNavbar_LWe7" id="cloning-the-apache-wayang-source-code">Cloning the Apache Wayang™ source code<a href="#cloning-the-apache-wayang-source-code" class="hash-link" aria-label="Direct link to Cloning the Apache Wayang™ source code" title="Direct link to Cloning the Apache Wayang™ source code">​</a></h3>
<p>If you are interested in working with the newest under-development code or contributing to Apache Spark development, you can check out the master branch from Git:</p>
<div class="codeBlockContainer_Ckt0 theme-code-block" style="--prism-color:#393A34;--prism-background-color:#f6f8fa"><div class="codeBlockContent_biex"><pre tabindex="0" class="prism-code language-text codeBlock_bY9V thin-scrollbar" style="color:#393A34;background-color:#f6f8fa"><code class="codeBlockLines_e6Vv"><span class="token-line" style="color:#393A34"><span class="token plain"># Master development branch</span><br></span><span class="token-line" style="color:#393A34"><span class="token plain">git clone git://github.com/apache/incubator-wayang.git</span><br></span></code></pre><div class="buttonGroup__atx"><button type="button" aria-label="Copy code to clipboard" title="Copy" class="clean-btn"><span class="copyButtonIcons_eSgA" aria-hidden="true"><svg viewBox="0 0 24 24" class="copyButtonIcon_y97N"><path fill="currentColor" d="M19,21H8V7H19M19,5H8A2,2 0 0,0 6,7V21A2,2 0 0,0 8,23H19A2,2 0 0,0 21,21V7A2,2 0 0,0 19,5M16,1H4A2,2 0 0,0 2,3V17H4V3H16V1Z"></path></svg><svg viewBox="0 0 24 24" class="copyButtonSuccessIcon_LjdS"><path fill="currentColor" d="M21,7L9,19L3.5,13.5L4.91,12.09L9,16.17L19.59,5.59L21,7Z"></path></svg></span></button></div></div></div>
<p>Once you’ve downloaded Wayang, you can find instructions for installing and building it on the <a href="/docs/guide/installation">Compiling Apache Wayang</a> page.</p>
<h3 class="anchor anchorWithStickyNavbar_LWe7" id="jira">JIRA<a href="#jira" class="hash-link" aria-label="Direct link to JIRA" title="Direct link to JIRA">​</a></h3>
<p>Generally, Wayang uses JIRA to track logical issues, including bugs and improvements, and uses GitHub pull requests to manage the review and merge of specific code changes. That is, JIRAs are used to describe what should be fixed or changed, and high-level approaches, and pull requests describe how to implement that change in the project’s source code. For example, major design decisions are discussed in JIRA.</p>
<ul>
<li>Find the existing Spark JIRA that the change pertains to.<!-- -->
<ul>
<li>Do not create a new JIRA if creating a change to address an existing issue in JIRA; add to the existing discussion and work instead</li>
<li>Look for existing pull requests that are linked from the JIRA, to understand if someone is already working on the JIRA</li>
</ul>
</li>
<li>If the change is new, then it usually needs a new JIRA. However, trivial changes, where the what should change is virtually the same as the how it should change do not require a JIRA. Example: <code>Fix typos in Foo wayang doc</code></li>
<li>If required, create a new JIRA:<!-- -->
<ul>
<li>Provide a descriptive Title. “Update web UI” or “Problem in scheduler” is not sufficient. “Kafka Streaming support fails to handle empty queue in YARN cluster mode” is good.</li>
<li>Write a detailed description. For bug reports, this should ideally include a short reproduction of the problem. For new features, it may include a design document.</li>
<li>Set required fields:<!-- -->
<ul>
<li>Issue Type. Generally, Bug, Improvement and New Feature are the only types used in Spark.</li>
<li>Priority. Set to Major or below; higher priorities are generally reserved for committers to set. The main exception is correctness or data-loss issues, which can be flagged as Blockers. JIRA tends to unfortunately conflate “size” and “importance” in its Priority field values. Their meaning is roughly:<!-- -->
<ul>
<li><strong>Blocker</strong>: pointless to release without this change as the release would be unusable to a large minority of users. Correctness and data loss issues should be considered Blockers for their target versions.</li>
<li><strong>Critical</strong>: a large minority of users are missing important functionality without this, and/or a workaround is difficult</li>
<li><strong>Major</strong>: a small minority of users are missing important functionality without this, and there is a workaround</li>
<li><strong>Minor</strong>: a niche use case is missing some support, but it does not affect usage or is easily worked around</li>
<li><strong>Trivial</strong>: a nice-to-have change but unlikely to be any problem in practice otherwise</li>
</ul>
</li>
<li>Component</li>
<li>Affects Version. For Bugs, assign at least one version that is known to exhibit the problem or need the change</li>
<li>Label. Not widely used, except for the following:<!-- -->
<ul>
<li><code>correctness</code>: a correctness issue</li>
<li><code>data-loss</code>: a data loss issue</li>
<li><code>release-notes</code>: the change’s effects need mention in release notes. The JIRA or pull request should include detail suitable for inclusion in release notes – see “Docs Text” below.</li>
<li><code>starter</code>: small, simple change suitable for new contributors</li>
</ul>
</li>
<li>Docs Text: For issues that require an entry in the release notes, this should contain the information that the release manager should include in Release Notes. This should include a short summary of what behavior is impacted, and detail on what behavior changed. It can be provisionally filled out when the JIRA is opened, but will likely need to be updated with final details when the issue is resolved.</li>
</ul>
</li>
<li>Do not set the following fields:<!-- -->
<ul>
<li><strong>Fix Version</strong> This is assigned by committers only when resolved.</li>
<li><strong>Target Version</strong> This is assigned by committers to indicate a PR has been accepted for possible fix by the target version.</li>
</ul>
</li>
<li>Do not include a patch file; pull requests are used to propose the actual change.</li>
</ul>
</li>
<li>If the change is a large change, consider inviting discussion on the issue at dev@ first before proceeding to implement the change.</li>
</ul>
<h3 class="anchor anchorWithStickyNavbar_LWe7" id="pull-request">Pull request<a href="#pull-request" class="hash-link" aria-label="Direct link to Pull request" title="Direct link to Pull request">​</a></h3>
<p>Before creating a pull request in Apache Wayang, it is important to check if tests can pass on your branch because our GitHub Actions workflows automatically run tests for your pull request/following commits and every run burdens the limited resources of GitHub Actions in Apache Wayang repository. Below steps will take your through the process.</p>
<ol>
<li>Fork the GitHub repository at <a href="https://github.com/apache/incubator-wayang" target="_blank" rel="noopener noreferrer">https://github.com/apache/incubator-wayang</a> if you haven’t already</li>
<li>Go to “Actions” tab on your forked repository and enable “Build and test” and “Report test results” workflows</li>
<li>Clone your fork and create a new branch</li>
<li>Consider whether documentation or tests need to be added or updated as part of the change, and add them as needed.<!-- -->
<ol>
<li>When you add tests, make sure the tests are self-descriptive.</li>
<li>Also, you should consider writing a JIRA ID in the tests when your pull request targets to fix a specific issue. In practice, usually it is added when a JIRA type is a bug or a PR adds a couple of tests to an existing test class. See the examples below:</li>
</ol>
</li>
</ol>
<div class="language-Java language-java codeBlockContainer_Ckt0 theme-code-block" style="--prism-color:#393A34;--prism-background-color:#f6f8fa"><div class="codeBlockContent_biex"><pre tabindex="0" class="prism-code language-java codeBlock_bY9V thin-scrollbar" style="color:#393A34;background-color:#f6f8fa"><code class="codeBlockLines_e6Vv"><span class="token-line" style="color:#393A34"><span class="token annotation punctuation" style="color:#393A34">@Test</span><span class="token plain"></span><br></span><span class="token-line" style="color:#393A34"><span class="token plain"></span><span class="token keyword" style="color:#00009f">public</span><span class="token plain"> </span><span class="token keyword" style="color:#00009f">void</span><span class="token plain"> </span><span class="token function" style="color:#d73a49">testCase</span><span class="token punctuation" style="color:#393A34">(</span><span class="token punctuation" style="color:#393A34">)</span><span class="token plain"> </span><span class="token punctuation" style="color:#393A34">{</span><span class="token plain"></span><br></span><span class="token-line" style="color:#393A34"><span class="token plain"> </span><span class="token comment" style="color:#999988;font-style:italic">// WAYANG-12345: a short description of the test</span><br></span></code></pre><div class="buttonGroup__atx"><button type="button" aria-label="Copy code to clipboard" title="Copy" class="clean-btn"><span class="copyButtonIcons_eSgA" aria-hidden="true"><svg viewBox="0 0 24 24" class="copyButtonIcon_y97N"><path fill="currentColor" d="M19,21H8V7H19M19,5H8A2,2 0 0,0 6,7V21A2,2 0 0,0 8,23H19A2,2 0 0,0 21,21V7A2,2 0 0,0 19,5M16,1H4A2,2 0 0,0 2,3V17H4V3H16V1Z"></path></svg><svg viewBox="0 0 24 24" class="copyButtonSuccessIcon_LjdS"><path fill="currentColor" d="M21,7L9,19L3.5,13.5L4.91,12.09L9,16.17L19.59,5.59L21,7Z"></path></svg></span></button></div></div></div>
<ol start="5">
<li>Consider whether benchmark results should be added or updated as part of the change, and add them as needed by Running benchmarks in your forked repository to generate benchmark results.</li>
<li>Run all tests with in your build to verify that the code still compiles, passes tests, and passes style checks. If style checks fail, review the Code Style Guide below.</li>
<li>Push commits to your branch. This will trigger “Build and test” and “Report test results” workflows on your forked repository and start testing and validating your changes.</li>
<li>Open a <a href="https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests" target="_blank" rel="noopener noreferrer">pull request</a> against the master branch of apache/incubator-wayang. (Only in special cases would the PR be opened against other branches). This will trigger workflows “On pull request*” (on the Wayang repo) that will look/watch for successful workflow runs on “your” forked repository (it will wait if one is running).<!-- -->
<ol>
<li>The PR title should be of the form [WAYANG-xxxx][COMPONENT] Title, where WAYANG-xxxx is the relevant JIRA number, COMPONENT is one of the PR categories and Title may be the JIRA’s title or a more specific title describing the PR itself.</li>
<li>If the pull request is still a work in progress, and so is not ready to be merged, but needs to be pushed to GitHub to facilitate review, then add [WIP] after the component.</li>
<li>Consider identifying committers or other contributors who have worked on the code being changed. Find the file(s) in GitHub and click “Blame” to see a line-by-line annotation of who changed the code last. You can add @username in the PR description to ping them immediately.</li>
<li>Please state that the contribution is your original work and that you license the work to the project under the project’s open source license.</li>
</ol>
</li>
<li>The related JIRA, if any, will be marked as “In Progress” and your pull request will automatically be linked to it. There is no need to be the Assignee of the JIRA to work on it, though you are welcome to comment that you have begun work.</li>
</ol>
<h3 class="anchor anchorWithStickyNavbar_LWe7" id="the-review-process">The review process<a href="#the-review-process" class="hash-link" aria-label="Direct link to The review process" title="Direct link to The review process">​</a></h3>
<ul>
<li>Other reviewers, including committers, may comment on the changes and suggest modifications. Changes can be added by simply pushing more commits to the same branch.</li>
<li>Lively, polite, rapid technical debate is encouraged from everyone in the community. The outcome may be a rejection of the entire change.</li>
<li>Keep in mind that changes to more critical parts of Spark, like its core and SQL components, will be subjected to more review, and may require more testing and proof of its correctness than other changes.</li>
<li>Reviewers can indicate that a change looks suitable for merging with a comment such as: “I think this patch looks good”. Wayang uses the LGTM convention for indicating the strongest level of technical sign-off on a patch: simply comment with the word “LGTM”. It specifically means: “I’ve looked at this thoroughly and take as much ownership as if I wrote the patch myself”. If you comment LGTM you will be expected to help with bugs or follow-up issues on the patch. Consistent, judicious use of LGTMs is a great way to gain credibility as a reviewer with the broader community.</li>
<li>Sometimes, other changes will be merged which conflict with your pull request’s changes. The PR can’t be merged until the conflict is resolved. This can be resolved by, for example, adding a remote to keep up with upstream changes by git remote add upstream <a href="https://github.com/apache/incubator-wayang.git" target="_blank" rel="noopener noreferrer">https://github.com/apache/incubator-wayang.git</a>, running git fetch upstream followed by git rebase upstream/master and resolving the conflicts by hand, then pushing the result to your branch.</li>
<li>Try to be responsive to the discussion rather than let days pass between replies</li>
</ul>
<h3 class="anchor anchorWithStickyNavbar_LWe7" id="closing-your-pull-request--jira">Closing your pull request / JIRA<a href="#closing-your-pull-request--jira" class="hash-link" aria-label="Direct link to Closing your pull request / JIRA" title="Direct link to Closing your pull request / JIRA">​</a></h3>
<ul>
<li>If a change is accepted, it will be merged and the pull request will automatically be closed, along with the associated JIRA if any<!-- -->
<ul>
<li>Note that in the rare case you are asked to open a pull request against a branch besides master, that you will actually have to close the pull request manually</li>
<li>The JIRA will be Assigned to the primary contributor to the change as a way of giving credit. If the JIRA isn’t closed and/or Assigned promptly, comment on the JIRA.</li>
</ul>
</li>
<li>If your pull request is ultimately rejected, please close it promptly<!-- -->
<ul>
<li>… because committers can’t close PRs directly</li>
<li>Pull requests will be automatically closed by an automated process at Apache after about a week if a committer has made a comment like “mind closing this PR?” This means that the committer is specifically requesting that it be closed.</li>
</ul>
</li>
<li>If a pull request has gotten little or no attention, consider improving the description or the change itself and ping likely reviewers again after a few days. Consider proposing a change that’s easier to include, like a smaller and/or less invasive change.</li>
<li>If it has been reviewed but not taken up after weeks, after soliciting review from the most relevant reviewers, or, has met with neutral reactions, the outcome may be considered a “soft no”. It is helpful to withdraw and close the PR in this case.</li>
<li>If a pull request is closed because it is deemed not the right approach to resolve a JIRA, then leave the JIRA open. However if the review makes it clear that the issue identified in the JIRA is not going to be resolved by any pull request (not a problem, won’t fix) then also resolve the JIRA.</li>
</ul>
<h2 class="anchor anchorWithStickyNavbar_LWe7" id="code-style-guide">Code style guide<a href="#code-style-guide" class="hash-link" aria-label="Direct link to Code style guide" title="Direct link to Code style guide">​</a></h2>
<p>Please follow the style of the existing codebase.</p>
<ul>
<li>For Python code, Apache Wayang follows <a href="http://legacy.python.org/dev/peps/pep-0008/" target="_blank" rel="noopener noreferrer">PEP 8</a> with one exception: lines can be up to 100 characters in length, not 79.</li>
<li>For R code, Apache Wayang follows <a href="https://google.github.io/styleguide/Rguide.xml" target="_blank" rel="noopener noreferrer">Google’s R Style Guide</a> with three exceptions: lines can be up to 100 characters in length, not 80, there is no limit on function name but it has a initial lower case latter and S4 objects/methods are allowed.</li>
<li>For Java code, Apache Wayang follows <a href="http://www.oracle.com/technetwork/java/codeconvtoc-136057.html" target="_blank" rel="noopener noreferrer">Oracle’s Java code conventions</a> and Scala guidelines below. The latter is preferred.</li>
<li>For Scala code, Apache Wayang follows the official <a href="http://docs.scala-lang.org/style/" target="_blank" rel="noopener noreferrer">Scala style guide</a>.</li>
</ul>
<h3 class="anchor anchorWithStickyNavbar_LWe7" id="if-in-doubt">If in doubt<a href="#if-in-doubt" class="hash-link" aria-label="Direct link to If in doubt" title="Direct link to If in doubt">​</a></h3>
<p>If you’re not sure about the right style for something, try to follow the style of the existing codebase. Look at whether there are other examples in the code that use your feature. Feel free to ask on the dev@ list as well and/or ask committers.</p>
<h2 class="anchor anchorWithStickyNavbar_LWe7" id="code-of-conduct">Code of conduct<a href="#code-of-conduct" class="hash-link" aria-label="Direct link to Code of conduct" title="Direct link to Code of conduct">​</a></h2>
<p>The Apache Wayang project follows the Apache Software Foundation Code of Conduct. The code of conduct applies to all spaces managed by the Apache Software Foundation, including IRC, all public and private mailing lists, issue trackers, wikis, blogs, Twitter, and any other communication channel used by our communities. A code of conduct which is specific to in-person events (ie., conferences) is codified in the published ASF anti-harassment policy.</p>
<p>We expect this code of conduct to be honored by everyone who participates in the Apache community formally or informally, or claims any affiliation with the Foundation, in any Foundation-related activities and especially when representing the ASF, in any role.</p>
<p>This code is not exhaustive or complete. It serves to distill our common understanding of a collaborative, shared environment and goals. We expect it to be followed in spirit as much as in the letter, so that it can enrich all of us and the technical communities in which we participate.</p>
<p>For more information and specific guidelines, refer to the Apache Software Foundation Code of Conduct.</p>
<p>This guide was originally released by <a href="https://spark.apache.org/contributing.html" target="_blank" rel="noopener noreferrer">Apache Spark</a>, the Apache Wayang project adapted the guide.</p></div></article><nav class="pagination-nav docusaurus-mt-lg" aria-label="Docs pages"><a class="pagination-nav__link pagination-nav__link--prev" href="/docs/community/committer"><div class="pagination-nav__sublabel">Previous</div><div class="pagination-nav__label">Becoming a committer</div></a><a class="pagination-nav__link pagination-nav__link--next" href="/docs/community/release"><div class="pagination-nav__sublabel">Next</div><div class="pagination-nav__label">How to make a release</div></a></nav></div></div><div class="col col--3"><div class="tableOfContents_bqdL thin-scrollbar theme-doc-toc-desktop"><ul class="table-of-contents table-of-contents__left-border"><li><a href="#contributing-by-helping-other-users" class="table-of-contents__link toc-highlight">Contributing by helping other users</a></li><li><a href="#contributing-by-testing-releases" class="table-of-contents__link toc-highlight">Contributing by testing releases</a></li><li><a href="#contributing-by-reviewing-changes" class="table-of-contents__link toc-highlight">Contributing by reviewing changes</a></li><li><a href="#contributing-documentation-changes" class="table-of-contents__link toc-highlight">Contributing documentation changes</a></li><li><a href="#contributing-user-libraries-to-wayang" class="table-of-contents__link toc-highlight">Contributing user libraries to Wayang</a></li><li><a href="#contributing-bug-reports" class="table-of-contents__link toc-highlight">Contributing bug reports</a><ul><li><a href="#contributing-to-jira-maintenance" class="table-of-contents__link toc-highlight">Contributing to JIRA maintenance</a></li><li><a href="#ml4all-and-optimizer-specific-contribution-guidelines" class="table-of-contents__link toc-highlight">ML4ALL and optimizer-specific contribution guidelines</a></li><li><a href="#code-review-criteria" class="table-of-contents__link toc-highlight">Code review criteria</a></li><li><a href="#contributing-code-changes" class="table-of-contents__link toc-highlight">Contributing code changes</a></li><li><a href="#cloning-the-apache-wayang-source-code" class="table-of-contents__link toc-highlight">Cloning the Apache Wayang™ source code</a></li><li><a href="#jira" class="table-of-contents__link toc-highlight">JIRA</a></li><li><a href="#pull-request" class="table-of-contents__link toc-highlight">Pull request</a></li><li><a href="#the-review-process" class="table-of-contents__link toc-highlight">The review process</a></li><li><a href="#closing-your-pull-request--jira" class="table-of-contents__link toc-highlight">Closing your pull request / JIRA</a></li></ul></li><li><a href="#code-style-guide" class="table-of-contents__link toc-highlight">Code style guide</a><ul><li><a href="#if-in-doubt" class="table-of-contents__link toc-highlight">If in doubt</a></li></ul></li><li><a href="#code-of-conduct" class="table-of-contents__link toc-highlight">Code of conduct</a></li></ul></div></div></div></div></main></div></div></div><footer class="footer footer--dark"><div class="container container-fluid"><div class="row footer__links"><div class="col footer__col"><div class="footer__title">Community</div><ul class="footer__items clean-list"><li class="footer__item"><a href="https://lists.apache.org/list.html?dev@wayang.apache.org" target="_blank" rel="noopener noreferrer" class="footer__link-item">Mailing list<svg width="13.5" height="13.5" aria-hidden="true" viewBox="0 0 24 24" class="iconExternalLink_nPIU"><path fill="currentColor" d="M21 13v10h-21v-19h12v2h-10v15h17v-8h2zm3-12h-10.988l4.035 4-6.977 7.07 2.828 2.828 6.977-7.07 4.125 4.172v-11z"></path></svg></a></li><li class="footer__item"><a href="https://www.youtube.com/@apachewayang" target="_blank" rel="noopener noreferrer" class="footer__link-item">YouTube<svg width="13.5" height="13.5" aria-hidden="true" viewBox="0 0 24 24" class="iconExternalLink_nPIU"><path fill="currentColor" d="M21 13v10h-21v-19h12v2h-10v15h17v-8h2zm3-12h-10.988l4.035 4-6.977 7.07 2.828 2.828 6.977-7.07 4.125 4.172v-11z"></path></svg></a></li><li class="footer__item"><a href="https://www.linkedin.com/company/apachewayang" target="_blank" rel="noopener noreferrer" class="footer__link-item">LinkedIn<svg width="13.5" height="13.5" aria-hidden="true" viewBox="0 0 24 24" class="iconExternalLink_nPIU"><path fill="currentColor" d="M21 13v10h-21v-19h12v2h-10v15h17v-8h2zm3-12h-10.988l4.035 4-6.977 7.07 2.828 2.828 6.977-7.07 4.125 4.172v-11z"></path></svg></a></li><li class="footer__item"><a href="https://www.reddit.com/r/ApacheWayang" target="_blank" rel="noopener noreferrer" class="footer__link-item">Reddit<svg width="13.5" height="13.5" aria-hidden="true" viewBox="0 0 24 24" class="iconExternalLink_nPIU"><path fill="currentColor" d="M21 13v10h-21v-19h12v2h-10v15h17v-8h2zm3-12h-10.988l4.035 4-6.977 7.07 2.828 2.828 6.977-7.07 4.125 4.172v-11z"></path></svg></a></li><li class="footer__item"><a href="https://twitter.com/apachewayang" target="_blank" rel="noopener noreferrer" class="footer__link-item">Twitter<svg width="13.5" height="13.5" aria-hidden="true" viewBox="0 0 24 24" class="iconExternalLink_nPIU"><path fill="currentColor" d="M21 13v10h-21v-19h12v2h-10v15h17v-8h2zm3-12h-10.988l4.035 4-6.977 7.07 2.828 2.828 6.977-7.07 4.125 4.172v-11z"></path></svg></a></li></ul></div><div class="col footer__col"><div class="footer__title">Documentation</div><ul class="footer__items clean-list"><li class="footer__item"><a class="footer__link-item" href="/docs/start/download">Install</a></li><li class="footer__item"><a class="footer__link-item" href="/docs/introduction/features">Features</a></li><li class="footer__item"><a class="footer__link-item" href="/docs/introduction/benchmark">Benchmark</a></li><li class="footer__item"><a class="footer__link-item" href="/docs/community/security">Security</a></li></ul></div><div class="col footer__col"><div class="footer__title">Repositories</div><ul class="footer__items clean-list"><li class="footer__item"><a href="https://github.com/apache/incubator-wayang" target="_blank" rel="noopener noreferrer" class="footer__link-item">Wayang<svg width="13.5" height="13.5" aria-hidden="true" viewBox="0 0 24 24" class="iconExternalLink_nPIU"><path fill="currentColor" d="M21 13v10h-21v-19h12v2h-10v15h17v-8h2zm3-12h-10.988l4.035 4-6.977 7.07 2.828 2.828 6.977-7.07 4.125 4.172v-11z"></path></svg></a></li><li class="footer__item"><a href="https://github.com/apache/incubator-wayang-website" target="_blank" rel="noopener noreferrer" class="footer__link-item">Website<svg width="13.5" height="13.5" aria-hidden="true" viewBox="0 0 24 24" class="iconExternalLink_nPIU"><path fill="currentColor" d="M21 13v10h-21v-19h12v2h-10v15h17v-8h2zm3-12h-10.988l4.035 4-6.977 7.07 2.828 2.828 6.977-7.07 4.125 4.172v-11z"></path></svg></a></li></ul></div></div><div class="footer__bottom text--center"><div class="margin-bottom--sm"><a href="https://incubator.apache.org/" rel="noopener noreferrer" class="footerLogoLink_BH7S"><img src="/img/apache-incubator.svg" alt="Apache Incubator logo" class="footer__logo themedComponent_mlkZ themedComponent--light_NVdE" width="200"><img src="/img/apache-incubator.svg" alt="Apache Incubator logo" class="footer__logo themedComponent_mlkZ themedComponent--dark_xIcU" width="200"></a></div><div class="footer__copyright"><div>
<p> Apache Wayang is an effort undergoing incubation at The Apache Software Foundation (ASF), sponsored by the Apache Incubator. Incubation is required of all newly accepted projects until a further review indicates that the infrastructure, communications, and decision making process have stabilized in a manner consistent with other successful ASF projects. While incubation status is not necessarily a reflection of the completeness or stability of the code, it does indicate that the project has yet to be fully endorsed by the ASF. </p>
<p>
Copyright © 2025 The Apache Software Foundation, Licensed under the Apache License, Version 2.0. <br>
Apache Wayang, Wayang, Apache, the Apache feather logo, and the Apache Wayang project logo are either registered trademarks or trademarks of The Apache Software Foundation in the United States and other countries. All other marks mentioned may be trademarks or registered trademarks of their respective owners.
</p>
</div></div></div></div></footer></div>
</body>
</html>