Podlings need to build a community in Apache in order to be accepted as part of the Apache Software Foundation. The podling website is one of the tools you use to build that community.
Podling Website Requirements
Podlings are, by definition, not yet fully accepted as part of the Apache Software Foundation. Therefore, they are subject to additional constraints on their websites. You MUST adhere to these policies before we can consider the podling for Graduation, unless you obtain prior approval from the Incubator PMC.
-
The published site for each podling must conform to the guidelines in Podling Branding/Publicity.
-
Podlings should review Corporate Recognition Best Practices, Apache trademark information, and must aim to comply with the Apache Project Website Branding Policy.
-
You should maintain the sources for the podling website in the podling’s SVN or Git repository.
-
The published site for each podling should conform to this URL space: http://podlingname.incubator.apache.org/ or http://podlingname.apache.org/
-
Every podling should maintain an incubation status file under: http://incubator.apache.org/projects/podlingname.html (this is generated).
Creating the Podling Website
Creating a Good Podling Site
Apache Project Web Sites typically include several standard pages. Each page has a navigation bar and a project standard header that includes the Incubator graphic.
You can establish the website during incubation, and migrate it after incubation to a permanent place in the TLP (Top Level Project) home.
-
Project Home Page: the primary entry point to the site; contains project description, news, invitation to join the project.
-
License Page: link to the Apache License 2.0.
-
Downloads: many projects in incubation release code, and this page describes the releases and has links to the download pages that redirect to Apache distribution system.
-
Documentation: this page presents the project documentation, including javadoc for Java projects, guides and tutorials, and links to external documentation.
-
Committers: a list of current committers on the project.
-
Mailing Lists: there are several mailing lists that the site visitors might be interested in, and this page contains
mailto:links that allow easy subscription (and unsubscription) to any of them. -
FAQ: answers to frequently asked questions.
-
Source Code: links to the browsable source repository and git or svn commands to check out the source code.
-
Issue Tracking: links to the Jira or other issue tracking tool, possibly including frequently-used filters for issue lists.
-
Dependencies: other projects that this project depends on.
-
favicon: the project’s icon in a format suitable for a browser’s address bar. If the favicon is absent, an Apache Feather displays.
Website Generation Tool
The podling can choose the tool it wishes to use to generate the website. The Infrastructure team provides guidance concerning tools that work best with Apache’s infrastructure, and what podlings and projects must avoid. If you already have a tool that you are comfortable with, you can probably continue to use it. If you do not, consider using the Jekyll based Apache website template.
Regardless of which tool you use, maintain the web site in the podling’s svn/git repository, and include instructions for using the site generation tool. This simplifies the process of site generation and lets any podling committer make changes to the site. Check the generated site into svn/git.
Publishing Your Website
Managing a podling’s website is the same as for a TLP (Top-Level Project). Review the Infra Documentation on Project Websites.
Using a Wiki to Create Documentation
Podlings may use a wiki to create documentation (including the website), providing that they follow the guidelines.
Web Site Transition
Projects may arrive with existing web sites that they host outside Apache. We strongly encourage contributing as much documentation as possible to the project from these sites. Offshore sites related to projects are fine, but you must host official websites for Apache projects with Apache (unless you obtain an explicit waiver).
Some projects elect to maintain previous releases outside Apache. In this case, they retain existing site is typically as a hub for this maintenance work. Otherwise, sites should link or redirect to the official Apache site.
Apache may accept donations of domains related to projects moving here. Infrastructure will then arrange for renewal of the domains and redirection of traffic to the official site. Contact infrastructure for more details.
Apache needs to deal with all commercial entities equitably. Linking to useful information on commercial sites is fine, but unfair discrimination between commercial sites is not. Most Apache projects find it better to simply link only to relevant articles on commercial sites rather than having to vet every request for links to commercial activity.