added resolutions

git-svn-id: https://svn.apache.org/repos/asf/jakarta/poi/trunk@352140 13f79535-47bb-0310-9956-ffa450edef68
This commit is contained in:
Andrew C. Oliver 2002-03-03 19:22:47 +00:00
parent 3fff56db5a
commit a280debe4e
4 changed files with 141 additions and 0 deletions

View File

@ -36,6 +36,7 @@
<menu-item label="Building" href="building.xml"/>
<menu-item label="XLS spec [PDF]" href="http://sc.openoffice.org/excelfileformat.pdf"/>
<menu-item label="Apache Cocoon" href="http://xml.apache.org/cocoon/"/>
<menu-item label="Resolutions" href="resolutions/index.html"/>
</menu>
<menu label="Get Involved">

View File

@ -0,0 +1,22 @@
<?xml version="1.0"?>
<!DOCTYPE book PUBLIC "-//APACHE//DTD Cocoon Documentation Book V1.0//EN" "../dtd/book-cocoon-v10.dtd">
<book software="Poi Project"
title="Resolutions"
copyright="@year@ Poi Project">
<menu label="Navigation">
<menu-item label="Main" href="../index.html"/>
</menu>
<menu label="About">
<menu-item label="About" href="index.html"/>
</menu>
<menu label="Resolutions">
<menu-item label="Coding Standards" href="res001.html"/>
</menu>
</book>

View File

@ -0,0 +1,37 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V1.0//EN" "../dtd/document-v10.dtd">
<document>
<header>
<title>Resolutons</title>
<subtitle>About this section</subtitle>
<authors>
<person name="Andrew C. Oliver" email="acoliver@apache.org"/>
</authors>
</header>
<body>
<s1 title="About Resolutions">
<p>
Every project on Jakarta has resolutions that they vote on.
Decisions are made, etc. But what happens once those decisions
are made? They are archived in the mail list archive never to
be read again (once its not in the top 10 or so posts). So they
get discussed again and again.
</p>
<p>
Rather than have that big waste of time, we have this section to
record important POI decisions. Once a decision is passed it
need only be linked to this page (either by creating a page for
it or by simply linking it to the archive messages). Wherever
possible a brief about how many votes for and against an maybe
some background should be posted.
</p>
<p>
This section is intended mainly to reduce big waste of time
discussions from taking away from whats important...developing
POI! :-D
</p>
</s1>
</body>
</document>

View File

@ -0,0 +1,81 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V1.0//EN" "../dtd/document-v10.dtd">
<document>
<header>
<title>POI Resoluton</title>
<subtitle>Resolution 001 - Minimal Coding Standards</subtitle>
<authors>
<person name="Andrew C. Oliver" email="acoliver@apache.org"/>
</authors>
</header>
<body>
<s1 title="Resolution 001 - Minimal Coding Standards">
<s2 title="Majority Position">
<p>
As the POI project has grown the "styles" used have become more
varied, some see this as a bad thing, but in reality it
can be a good thing. Each can learn from the different
styles by working with different code. That being said
there are some universal "good quality" guidelines that
must be adopted on a project of any proportions.
</p>
<p>
Marc Johnson Authored the following resolution:
</p>
<p>
On Tue, 2002-01-08 at 22:23, Marc Johnson wrote:
Standards are wonderful; everyone should have a set.
Here's what I propose for coding standards for POI WRT comments (should I
feel the need, I'll post more of these little gems):
</p>
<ol>
<li>
All classes and interfaces MUST have, right at the beginning, the POI
License (see poi/doc/LICENSE).
</li>
<li>
All classes and interfaces MUST include class javadoc. Conventionally,
this goes after the package and imports, and before the start of the class
or interface. The class javadoc MUST have at least one @author tag
</li>
<li>
All methods that are accessible outside the class MUST have javadoc
comments. In other words, if it isn't private, it MUST have javadoc
comments. Simple getters can consist of a simple @return tag; simple setters
can consist of a simple @param tag. Anything else requires some verbiage
plus all the standard javadoc tags as appropriate. You MUST include @throws
or @exception for any non-runtime exceptions, and you SHOULD document any
runtime exceptions you expect to throw. @throws/@exception tags SHOULD
include an explanation of why that exception would be thrown. If your method
might return null, you MUST say so. An accompanying explanation of the
circumstances for doing so would be nice.
</li>
</ol>
</s2>
<s2 title="Amendments (informal by extension and not by vote)">
<p>
As opposed to the formerly used POI License which was
based on the Apache Public License, now that POI is part of
Jakarta, use the APL 1.1 for the header. Currently, the
Apache Software Foundation requires us to use the full
long version.
</p>
</s2>
<s2 title="Dissent">
<p>
The motion was passed unanimously with no negative or
positive votes.
</p>
</s2>
<s2 title="Comments">
<p>
Andy didn't feel like going through his mail and sucking
out the comments.. If there is anything you feel should
be added here do it yourself ;-).
</p>
</s2>
</s1>
</body>
</document>