[MINOR] Heading/Title fixes
diff --git a/site/community.md b/site/community.md
index e54d30f..b52b27f 100644
--- a/site/community.md
+++ b/site/community.md
@@ -25,9 +25,7 @@
{% include JB/setup %}
-<br/><br/><br/>
-
-## {{ site.data.project.name }} Community
+# {{ site.data.project.name }} Community
Every volunteer project obtains its strength from the people involved in it. We invite you to participate as much or as little as you choose.
diff --git a/site/contributing-extensions.md b/site/contributing-extensions.md
index 73daa57..a0b97de 100644
--- a/site/contributing-extensions.md
+++ b/site/contributing-extensions.md
@@ -23,11 +23,13 @@
{% endcomment %}
-->
+# Contributing new Extensions to {{ site.data.project.name }}
+
Apache Bahir provides extensions to distributed analytic platforms such as Apache Spark. In the context of Apache Spark, extensions can be Streaming connectors, SQL data sources, etc
This document explains the process for proposing a new extension to Apache Bahir, and how the extension lifecycle are handled in the project.
-# Proposing a new extension
+## Proposing a new extension
In Apache Bahir we believe that forming a community around these extensions will actually make it better, and extend its life cycle, thus we require that new extensions be discussed on the project mailing list and receive at least 3 +1 from other committers.
@@ -35,7 +37,7 @@
Once a proposed extension gets the necessary votes, the author should follow the regular contribution process, creating a jira if one is not available yet, and provide a pull request.
-# What is expected of a new extension
+## What is expected of a new extension
Extensions must provide:
@@ -47,18 +49,18 @@
1. **Example**: a simple application that can serve as a reference point on how to use the extension in an application. Users must be able to simply build and deploy the sample application into a cluster.
-# Extension life cycle
+## Extension life cycle
We understand that software, particularly open source one, evolves quite quickly, and thus we antecipate that some extensions might start to lag behind in its maintenance.
The steps described below were crafted with the intention to alleviate the side-effects of one extension lagging behind and becoming broke for one reason or another.
-## Retiring extensions
+### Retiring extensions
When a particular extension breaks a build, it will be removed from the build (TBD the actual period here) to minimize the impact on the community.
Extensions that stay out of the build for a period of time (TBD the actual period here) will be retired to an 'contrib' folder, and at that point will not be part of the official releases.
-## Resurecting a retired extension
+### Resurecting a retired extension
At any point, a community member can request to resurect a retired extension, and at this point, the process is the same as the initial extension proposal, where he would propose the extension to be brought to life again, and would need to receive at least 3 +1 from other committers.
diff --git a/site/contributing.md b/site/contributing.md
index 957f4de..0d996bb 100644
--- a/site/contributing.md
+++ b/site/contributing.md
@@ -23,19 +23,21 @@
{% endcomment %}
-->
+# Contributing to {{ site.data.project.name }} Community
+
This guide documents the best way to make various types of contribution to Apache Bahir, including what is required before submitting a code change and how to properly merge them.
Contributing to Bahir doesn't just mean writing code. Helping testing and reviewing pull requests 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.
-#Contributing by Helping Other Users
+## Contributing by Helping Other Users
A great way to contribute to Bahir is to help answer user questions on the [user@bahir.apache.org]({{ site.data.project.user_list_archive_mailarchive }}) mailing list. There are always many new users; taking a few minutes to help answer a question is a very valuable community service.
Contributors should subscribe to this list and follow it in order to keep up to date on what's happening in Bahir. Answering questions is an excellent and visible way to help the community, which also demonstrates your expertise.
-#Contributing by Testing Releases
+## Contributing by Testing Releases
Bahir's release process is community-oriented, and members of the community can vote on new releases on the [dev@bahir.apache.org]({{ site.data.project.dev_list_archive_mailarchive }}) mailing list. Bahir users are invited to subscribe to this list to receive announcements of release vote, and test Bahir extensions on newer release and provide feedback on any performance or correctness issues found in the newer release.
@@ -49,7 +51,7 @@
{% endcomment %}
-->
-# Contributing code changes
+## Contributing code changes
Please review the preceding section before proposing a code change. This section documents how to do so:
@@ -64,7 +66,7 @@
1. [The Review Process](#The+Review+Process)
4. [Merging Pull Requests](#Merging+Pull+Requests)
-## JIRA
+### JIRA
Bahir uses JIRA to track 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.
@@ -92,7 +94,7 @@
1. If the change is a large change, consider inviting discussion on the issue at dev@bahir.apache.org first before proceeding to implement the change.
-## Before creating a Pull Request
+### Before creating a Pull Request
Fork the Github repository at https://github.com/apache/bahir and clone your fork if you haven't already
@@ -131,7 +133,7 @@
To fix the conflict, you can follow [the standard procedures for resolving merge conflicts from the command line](https://help.github.com/articles/resolving-a-merge-conflict-from-the-command-line). When you're finished, you'll need to call **git rebase --continue** in order for Git to continue processing the rest of the rebase.
-##Creating a Pull Request
+### Creating a Pull Request
1. Create a new branch, push commits to the branch.
1. Consider whether documentation or tests need to be added or updated as part of the change, and add them as needed.
@@ -155,7 +157,7 @@
if there is sufficient memory.
-##Code Review Criteria
+### Code Review Criteria
Before considering how to contribute code, it's useful to understand how code is reviewed, and why changes may be rejected. 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.
**Positives**
@@ -178,7 +180,7 @@
* Adds a large amount of code
* Makes lots of modifications in one "big bang" change
-##The Review Process
+### The Review Process
* 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.
* Lively, polite, rapid technical debate is encouraged from everyone in the community. The outcome may be a rejection of the entire change.
