Apache
/
poi
mirror of https://github.com/apache/poi.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Update the contributor guidelines (microsoft docs, smaller patches are better etc), and ensure we only have the one copy in /guidelines.html 

git-svn-id: https://svn.apache.org/repos/asf/poi/trunk@960038 13f79535-47bb-0310-9956-ffa450edef68
This commit is contained in:
Nick Burch 2010-07-02 15:51:48 +00:00
parent f71a66b0ab
commit 4a3e42987e
15 changed files with 81 additions and 379 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
src/documentation/content/xdocs/casestudies.xml
View File

@ -46,7 +46,7 @@
<p>
We are actively seeking case studies for this page (after all it
just started). To submit a case study, either
<link href="getinvolved/index.html">
<link href="guidelines.html">
submit a patch for this page</link> or email it to the
<link href="mailinglists.html">mailing list
</link> (with [PATCH] prefixed subject, please).

38
src/documentation/content/xdocs/getinvolved/book.xml
View File

@ -1,38 +0,0 @@
<?xml version="1.0" encoding="UTF-8"?>
<!--
====================================================================
Licensed to the Apache Software Foundation (ASF) under one or more
contributor license agreements. See the NOTICE file distributed with
this work for additional information regarding copyright ownership.
The ASF licenses this file to You under the Apache License, Version 2.0
(the "License"); you may not use this file except in compliance with
the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
====================================================================
-->
<!DOCTYPE book PUBLIC "-//APACHE//DTD Cocoon Documentation Book V1.0//EN" "./dtd/book-cocoon-v10.dtd">
<book software="POI"
title="POI Project Documentation"
copyright="@year@ POI Project"
xmlns:xlink="http://www.w3.org/1999/xlink">
<menu label="Apache POI">
<menu-item label="Top" href="../index.html"/>
</menu>
<menu label="Get Involved">
<menu-item label="Contributing" href="index.html"/>
<menu-item label="Branching" href="branching.html"/>
<menu-item label="Subversion" href="../subversion.html"/>
<menu-item label="Mail Lists" href="../mailinglists.html"/>
</menu>
</book>

115
src/documentation/content/xdocs/getinvolved/branching.xml
View File

@ -1,115 +0,0 @@
<?xml version="1.0" encoding="UTF-8"?>
<!--
====================================================================
Licensed to the Apache Software Foundation (ASF) under one or more
contributor license agreements. See the NOTICE file distributed with
this work for additional information regarding copyright ownership.
The ASF licenses this file to You under the Apache License, Version 2.0
(the "License"); you may not use this file except in compliance with
the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
====================================================================
-->
<!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V1.1//EN" "./dtd/document-v11.dtd">
<document>
<header>
<title>Branching</title>
<authors>
<person id="GJS" name="Glen Stampoultzis" email="user@poi.apache.org"/>
</authors>
</header>
<body>
<section><title>Branching Conventions</title>
<p>
Branches are tagged in the following way:
</p>
<ul>
<li>REL_1_5_BRANCH</li>
<li>REL_2_0_BRANCH</li>
</ul>
<p>
Merge points should be tagged as follows:
</p>
<ul>
<li>REL_1_5_BRANCH_MERGE1</li>
<li>REL_1_5_BRANCH_MERGE2</li>
<li>etc...</li>
</ul>
<p>
Releases should be tagged as:
</p>
<ul>
<li>REL_1_5</li>
<li>REL_1_5_1</li>
<li>REL_1_5_2</li>
<li>etc...</li>
</ul>
</section>
<section><title>Branching Advise</title>
<p>
Don't forget which branch you are currently on. This is critically
important. Committing stuff to the wrong branch causes all sorts of
headaches. Best to name your checkout after the branch you are on.
</p>
</section>
<section><title>Who Manages Branching?</title>
<p>
All branching is currently managed by Glen Stampoultzis. If you wish
to create your own branch please let him know. Merging is also
handled by Glen. Just pop him a mail if you feel it's necessary to
create a branch or perform a merge.
</p>
<p>
The reason to go through a single point for branching is that it can be
an easy thing to get wrong. Having a single person managing branches
means there is less chance of getting getting our wires crossed with this
difficult area of CVS.
</p>
</section>
<section><title>Currently Active Branches</title>
<p>
The following branches are currently active:
</p>
<table>
<tr>
<th>
Branch
</th>
<th>
Description
</th>
</tr>
<tr>
<td>
HEAD
</td>
<td>
This is the trunk and is always active. Currently it is being used to continue development
of the 2.0 release.
</td>
</tr>
<tr>
<td>
REL_1_5_BRANCH
</td>
<td>
All bug fixes not specifically relevant to the 2.0 work should be placed in this branch.
From here they will merged back to the trunk and the merge point marked.
</td>
</tr>
</table>
</section>
</body>
</document>

197
src/documentation/content/xdocs/getinvolved/index.xml
View File

@ -1,197 +0,0 @@
<?xml version="1.0" encoding="UTF-8"?>
<!--
====================================================================
Licensed to the Apache Software Foundation (ASF) under one or more
contributor license agreements. See the NOTICE file distributed with
this work for additional information regarding copyright ownership.
The ASF licenses this file to You under the Apache License, Version 2.0
(the "License"); you may not use this file except in compliance with
the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
====================================================================
-->
<!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V1.1//EN" "./dtd/document-v11.dtd">
<document>
<header>
<title>Contribution to POI</title>
<authors>
<person name="Nicola Ken Barozzi" email="barozzi@nicolaken.com"/>
<person name="Marc Johnson" email="mjohnson@apache.org"/>
<person name="Andrew C. Oliver" email="acoliver@apache.org"/>
<person name="Tetsuya Kitahata" email="tetsuya.kitahata@nifty.com"/>
</authors>
</header>
<body>
<section><title>Introduction</title>
<section><title>Disclaimer</title>
<p>
Any information in here that might be perceived as legal information is
informational only. We're not lawyers, so consult a legal professional
if needed.
</p>
</section>
<section><title>The Licensing</title>
<p>
The POI project is <link href="http://www.opensource.org">OpenSource</link>
and developed/distributed under the <link
href="http://www.apache.org/foundation/licence-FAQ.html">
Apache Software License</link>. Unlike other licenses this license allows
free open source development; however, it does not require you to release
your source or use any particular license for your source. If you wish
to contribute to POI (which you're very welcome and encouraged to do so)
then you must agree to release the rights of your source to us under this
license.
</p>
</section>
<section><title>Publicly Available Information on the file formats</title>
<p>
In early 2008, Microsoft made a fairly complete set of documentation
on the binary file formats freely and publicly available. These were
released under the <link href="http://www.microsoft.com/interop/osp">Open
Specification Promise</link>, which does allow us to use them for
building open source software under the <link
href="http://www.apache.org/foundation/licence-FAQ.html">
Apache Software License</link>.
</p>
<p>
You can download the documentation on Excel, Word, PowerPoint and
Escher (drawing) from
<link href="http://www.microsoft.com/interop/docs/OfficeBinaryFormats.mspx">http://www.microsoft.com/interop/docs/OfficeBinaryFormats.mspx</link>.
Documentation on a few of the supporting technologies used in these
file formats can be downloaded from
<link href="http://www.microsoft.com/interop/docs/supportingtechnologies.mspx">http://www.microsoft.com/interop/docs/supportingtechnologies.mspx</link>.
</p>
<p>
Previously, Microsoft published a book on the Excel 97 file format.
It can still be of plenty of use, and is handy dead tree form. Pick up
a copy of "Excel 97 Developer's Kit" from your favourite second hand
book store.
</p>
<p>
The newer Office Open XML (ooxml) file formats are documented as part
of the ECMA / ISO standardisation effort for the formats. This
documentation is quite large, but you can normally find the bit you
need without too much effort! This can be downloaded from
<link href="http://www.ecma-international.org/publications/standards/Ecma-376.htm">http://www.ecma-international.org/publications/standards/Ecma-376.htm</link>,
and is also under the <link href="http://www.microsoft.com/interop/osp">OSP</link>.
</p>
<p>
It is also worth checking the documentation and code of the other
open source implementations of the file formats.
</p>
</section>
<section><title>I just signed an NDA to get a spec from Microsoft and I'd like to contribute</title>
<p>
In short, stay away, stay far far away. Implementing these file formats
in POI is done strictly by using public information. Public information
includes sources from other open source projects, books that state the
purpose intended is for allowing implementation of the file format and
do not require any non-disclosure agreement and just hard work.
We are intent on keeping it
legal, by contributing patches you agree to do the same.
</p>
<p>
If you've ever received information regarding the OLE 2 Compound Document
Format under any type of exclusionary agreement from Microsoft, or
(possibly illegally) received such information from a person bound by
such an agreement, you cannot participate in this project. (Sorry)
</p>
<p>
Those submitting patches that show insight into the file format may be
asked to state explicitly that they have only ever read the publicly
available file format information, and not any received under an NDA
or similar.
</p>
</section>
</section>
<section><title>I just want to get involved but don't know where to start</title>
<ul>
<li>Read the rest of the website, understand what POI is and what it does,
the project vision, etc.</li>
<li>Use POI a bit, look for gaps in the documentation and examples.</li>
<li>Join the <link href="../mailinglists.html">mailing lists</link> and share your knowledge with others.</li>
<li>Get <link href="../subversion.html">Subversion</link> and check out the POI source tree</li>
<li>Documentation is always the best place to start contributing, maybe you found that if the documentation just told you how to do X then it would make more sense, modify the documentation.</li>
<li>Contribute examples - if there's something people are often asking about on the <link href="../mailinglists.html">user list</link> which isn't covered in the documentation or current examples, try writing an example of this and uploading it as a patch.</li>
<li>Get used to building POI, you'll be doing it a lot, be one with the build, know its targets, etc.</li>
<li>Write Unit Tests. Great way to understand POI. Look for classes that aren't tested, or aren't tested on a public/protected method level, start there.</li>
<li>Download the file format documentation from Microsoft -
<link href="http://www.microsoft.com/interop/docs/OfficeBinaryFormats.mspx">OLE2 Binary File Formats</link> or
<link href="http://www.ecma-international.org/publications/standards/Ecma-376.htm">OOXML XML File Formats</link></li>
<li>Submit patches (see below) of your contributions, modifications.</li>
<li>Check the <link href="http://issues.apache.org/bugzilla/buglist.cgi?product=POI">bug database</link> for simple problem reports, and write a patch to fix the problem</li>
<li>Add in new features, see <link href="http://issues.apache.org/bugzilla/buglist.cgi?product=POI">Bug database</link> for suggestions.</li>
</ul>
<p>The Nutch project also have a very useful guide on becoming a
new developer in their project. While it is written for their project,
a large part of it will apply to POI too. You can read it at
<link href="http://wiki.apache.org/nutch/Becoming_A_Nutch_Developer">http://wiki.apache.org/nutch/Becoming_A_Nutch_Developer</link></p>
</section>
<section><title>Submitting Patches</title>
<p>
Create patches by getting the latest sources from Subversion.
Alter or add files as appropriate. Then, from the poi directiory,
type svn diff > mypatch.patch. This will capture all of your changes
in a patch file of the appropriate format. However, svn diff won't
capture any new files you may have added. So, if you've added any
files, create an archive (tar.bz2 preferred as its the smallest) in a
path-preserving archive format, relative to your poi directory.
You'll attach both files in the next step.
</p>
<p>
Patches are submitted via the <link href="http://issues.apache.org/bugzilla/buglist.cgi?product=POI">Bug Database</link>.
Create a new bug, set the subject to [PATCH] followed by a brief description. Explain you patch and any special instructions and submit/save it.
Next, go back to the bug, and create attachements for the patch files you
created. Be sure to describe not only the files purpose, but its format.
(Is that ZIP or a tgz or a bz2 or what?).
</p>
<p>
Make sure your patches include the @author tag on any files you've altered
or created. Make sure you've documented your changes and altered the
examples/etc to reflect them. Any new additions should have unit tests.
Lastly, ensure that you've provided approriate javadoc. (see
<link href="http://poi.apache.org/resolutions/res001.html">Coding
Standards</link>). Patches that are of low quality may be rejected or
the contributer may be asked to bring them up to spec.
</p>
<p>If you use a unix shell, you may find the following following
sequence of commands useful for building the files to attach.</p>
<source>
# Run this in the root of the checkout, i.e. the directory holding
# build.xml and poi.pom
# Build the directory to hold new files
mkdir /tmp/poi-patch/
mkdir /tmp/poi-patch/new-files/
# Get changes to existing files
svn diff > /tmp/poi-patch/diff.txt
# Capture any new files, as svn diff won't include them
# Preserve the path
svn status | grep "^\?" | awk '{printf "cp --parents %s /tmp/poi-patch/new-files/\n", $2 }' | sh -s
# tar up the new files
cd /tmp/poi-patch/new-files/
tar jcvf ../new-files.tar.bz2
cd ..
# Upload these to bugzilla
echo "Please upload to bugzilla:"
echo " /tmp/poi-patch/diff.txt"
echo " /tmp/poi-patch/new-files.tar.bz2"
</source>
</section>
</body>
</document>

86
src/documentation/content/xdocs/guidelines.xml
View File

@ -23,10 +23,8 @@
<header>
<title>Apache POI - Contribution Guidelines</title>
<authors>
<person name="Nicola Ken Barozzi" email="barozzi@nicolaken.com"/>
<person name="Marc Johnson" email="mjohnson@apache.org"/>
<person name="Andrew C. Oliver" email="acoliver@apache.org"/>
<person name="Tetsuya Kitahata" email="tetsuya.kitahata@nifty.com"/>
<person name="Nick Burch" email="dev@poi.apache.org"/>
<person name="David Fisher" email="dev@poi.apache.org"/>
</authors>
</header>
@ -93,24 +91,30 @@
<section><title>I just signed an NDA to get a spec from Microsoft and I'd like to contribute</title>
<p>
In short, stay away, stay far far away. Implementing these file formats
in POI is done strictly by using public information. Public information
in POI is done strictly by using public information. Most of this Public
Information currently comes from the documentation that Microsoft
makes freely available (see above). The rest of the public information
includes sources from other open source projects, books that state the
purpose intended is for allowing implementation of the file format and
do not require any non-disclosure agreement and just hard work.
We are intent on keeping it
legal, by contributing patches you agree to do the same.
We are intent on keeping it legal, by contributing patches you agree to
do the same.
</p>
<p>
If you've ever received information regarding the OLE 2 Compound Document
Format under any type of exclusionary agreement from Microsoft, or
(possibly illegally) received such information from a person bound by
such an agreement, you cannot participate in this project. (Sorry)
received such information from a person bound by such an agreement, you
cannot participate in this project. Sorry. Well, unless you can persuade
Microsoft to release you from the terms of the NDA on the grounds that
most of the information is now publically available. However, if you have
been party to a Microsoft NDA, you will need to get clearance from Microsoft
before contributing.
</p>
<p>
Those submitting patches that show insight into the file format may be
asked to state explicitly that they have only ever read the publicly
available file format information, and not any received under an NDA
or similar.
or similar, and have only made us of the public documentation.
</p>
</section>
</section>
@ -130,12 +134,15 @@
<link href="http://www.ecma-international.org/publications/standards/Ecma-376.htm">OOXML XML File Formats</link></li>
<li>Submit patches (see below) of your contributions, modifications.</li>
<li>Check the <link href="http://issues.apache.org/bugzilla/buglist.cgi?product=POI">bug database</link> for simple problem reports, and write a patch to fix the problem</li>
<li>Review existing patches in the <link href="http://issues.apache.org/bugzilla/buglist.cgi?product=POI">bug database</link>, and report if they still apply, if they need unit tests atc.</li>
<li>Add in new features, see <link href="http://issues.apache.org/bugzilla/buglist.cgi?product=POI">Bug database</link> for suggestions.</li>
</ul>
<p>The Nutch project also have a very useful guide on becoming a
new developer in their project. While it is written for their project,
a large part of it will apply to POI too. You can read it at
<link href="http://wiki.apache.org/nutch/Becoming_A_Nutch_Developer">http://wiki.apache.org/nutch/Becoming_A_Nutch_Developer</link></p>
<link href="http://wiki.apache.org/nutch/Becoming_A_Nutch_Developer">http://wiki.apache.org/nutch/Becoming_A_Nutch_Developer</link>. The
<link href="http://community.apache.org/">Apache Community Development
Project</link> also provides guidance and mentoring for new contributors.</p>
</section>
<section><title>Submitting Patches</title>
<p>
@ -148,6 +155,19 @@
path-preserving archive format, relative to your poi directory.
You'll attach both files in the next step.
</p>
<p>
Ideally, patches should be submitted early and often. This is for
two key reasons. Firstly, it's much easier to review smaller patches
than large ones. This means that smaller patches are much more likely
to be applied to SVN in a timely fashion. Secondly, by sending in your
patches earlier rather than later, it's much easier to get feedback
on your coding and direction. If you've missed an easier way to do something,
or are duplicating some (probably hidden) existing code, or taking things
in an unusual direction, it's best to get the feedback sooner rather than
later! As such, when submitting patches to POI, as with other Apache
Software Foundation projects, do please try to submit early and often, rather
than "throwing a large patch over the wall" at the end.
</p>
<p>
Patches are submitted via the <link href="http://issues.apache.org/bugzilla/buglist.cgi?product=POI">Bug Database</link>.
Create a new bug, set the subject to [PATCH] followed by a brief description. Explain you patch and any special instructions and submit/save it.
@ -179,8 +199,7 @@ svn diff > /tmp/poi-patch/diff.txt
# Capture any new files, as svn diff won't include them
# Preserve the path
svn status | grep "^\?" | \
awk '{printf "cp --parents %s /tmp/poi-patch/new-files/\n", $2 }' | sh -s
svn status | grep "^\?" | awk '{printf "cp --parents %s /tmp/poi-patch/new-files/\n", $2 }' | sh -s
# tar up the new files
cd /tmp/poi-patch/new-files/
@ -194,10 +213,43 @@ echo " /tmp/poi-patch/new-files.tar.bz2"
</source>
</section>
<section><title>Mentoring and Committership</title>
<p>The POI project will generally offer committership to contributors who send
in consistently good patches over a period of several months.</p>
<p>The requirement for "good patches" generally means patches which can be applied
to SVN with little or no changes. These patches should include unit test, and
appropriate documentation. Whilst your first patch to POI may require quite a
bit of work before it can be committed by an existing committer, with any luck
your later patches will be applied with no / minor tweaks. Please do take note
of any changes required by your earlier patches, to learn for later ones! If
in doubt, ask on the <link href="mailinglists.html">dev mailing list</link>.</p>
<p>The requirement for patches over several months is to ensure that committers
remain with the project. It's very easy for a good developer to fire off half
a dozen good patches in the couple of weeks that they're working on a POI
powered project. However, if that developer then moves away, and stops
contributing to POI after that spurt, then they're not a good candidate for
committership. As such, we generally require people to stay around for a while,
submitting patches and helping on the mailing list before considering them
for committership.</p>
<p>Where possible, patches should be submitted early and often. For more details
on this, please see the "Submitting Patches" section above.</p>
<p>Where possible, the existing developers will try to help and mentor new
contributors. However, everyone involved in POI is a volunteer, and it may
happen that your first few patches come in at a time when all the committers
are very busy. Do please have patience, and remember to use the
<link href="mailinglists.html">dev mailing list</link> so that other
contributors can assist you!</p>
<p>For more information on getting started at Apache, mentoring, and local
Apache Committers near you who can offer advice, please see the
<link href="http://community.apache.org/">Apache Community Development
Project</link> website.</p>
</section>
</body>
<footer>
<legal>
<footer>
<legal>
Copyright (c) @year@ The Apache Software Foundation. All rights reserved.
</legal>
</footer>
</legal>
</footer>
</document>

4
src/documentation/content/xdocs/hwpf/index.xml
View File

@ -68,7 +68,7 @@
<p>If you come across a feature in XWPF that you need, and isn't currently
there, please do send in a patch to add the extra functionality! More details
on contributing patches are available on the <link
href="../getinvolved/index.html">"Contribution to POI" page</link>.</p>
href="../guidelines.html">"Contribution to POI" page</link>.</p>
</section>
<section>
@ -122,7 +122,7 @@
code easily. If you need any help getting started with JUnit test cases
for HWPF, please ask on the developers' mailing list! If you show that you
are prepared to stick at it you will most likely be given SVN commit
access. See <link href="../getinvolved/index.html">"Contribution to POI" page</link>
access. See <link href="../guidelines.html">"Contribution to POI" page</link>
for more details and help getting started.</p>
<p>Of course we will help you as best as we can. However, presently there

2
src/documentation/content/xdocs/plan/index.xml
View File

@ -50,7 +50,7 @@
<p>Anyone can participate in this process. Please get involved in discussion
on <code>dev</code> and contribute patches for these summary planning
documents via the normal <link href="../getinvolved/index.html">contribution</link>
documents via the normal <link href="../guidelines.html">contribution</link>
process.
</p>

2
src/documentation/content/xdocs/spreadsheet/hacking-hssf.xml
View File

@ -83,7 +83,7 @@
and work your way up.</p>
</section>
<section><title>What Else Should I Know?</title>
<p>Make sure you <link href="../getinvolved/index.html">read the contributing section</link>
<p>Make sure you <link href="../guidelines.html">read the contributing section</link>
as it contains more generation information about contributing to POI in general.</p>
</section>
</body>

2
src/documentation/content/xdocs/spreadsheet/how-to.xml
View File

@ -736,7 +736,7 @@ yet. When it does something, we'll document it.</p>
<li>Performance: POI currently uses a lot of memory for large sheets.</li>
<li>Charts: This is a hard problem, with very little documentation.</li>
</ul>
<p><link href="../getinvolved/index.html"> So jump in! </link> </p>
<p><link href="../guidelines.html"> So jump in! </link> </p>
</section>

2
src/documentation/content/xdocs/subversion.xml
View File

@ -70,7 +70,7 @@
<p>If you are not a <em>Committer</em>, but you want to submit patches
or even request commit privileges, please see our
<link href="getinvolved/index.html">Guidelines</link> for more
<link href="guidelines.html">Guidelines</link> for more
information.</p>
</section>
<section><title>Git access to POI sources </title>

2
src/documentation/content/xdocs/trans/de/book.xml
View File

@ -42,7 +42,7 @@
<menu-item label="Neuigkeiten" href="../../news.html"/>
<menu-item label="Änderungen" href="../../changes.html"/>
<menu-item label="Aufgaben" href="../../todo.html"/>
<menu-item label="Mitmachen" href="../../getinvolved/index.html"/>
<menu-item label="Mitmachen" href="../../guidelines.html"/>
<menu-item label="Unsere Vision" href="../../plan/POI20Vision.html"/>
<menu-item label="Vergangenheit und Zukunft" href="../../historyandfuture.html"/>
<menu-item label="Wer wir sind" href="../../who.html"/>

2
src/documentation/content/xdocs/trans/es/book.xml
View File

@ -47,7 +47,7 @@
<menu-item label="Espejos [EN]" href="../../mirrors.html"/>
<menu-item label="Cambios [EN]" href="../../changes.html"/>
<menu-item label="Tareas" href="todo.html"/>
<menu-item label="Contribuya [EN]" href="../../getinvolved/index.html"/>
<menu-item label="Contribuya [EN]" href="../../guidelines.html"/>
<menu-item label="Listas de Correo" href="http://jakarta.apache.org/site/mail2.html#poi"/>
<menu-item label="Visión [EN]" href="../../plan/POI20Vision.html"/>
<menu-item label="Historia y Futuro" href="historyandfuture.html"/>

2
src/documentation/content/xdocs/trans/es/casestudies.xml
View File

@ -48,7 +48,7 @@
acaba de comenzarse). Andrew C. Oliver (acoliver at apache dot org) ha
accedido a entregar unas cuantas Camisetas con el logotipo de POI para
los primeros y mejores envíos. Para enviar un estudio de un caso, puedes
<link href="http://jakarta.apache.org/poi/getinvolved/index.html">
<link href="http://jakarta.apache.org/poi/guidelines.html">
enviar un parche para esta página</link> o enviarlo por correo electrónico
a la <link href="http://jakarta.apache.org/site/mail2.html#poi">lista de correo
</link> (con [PATCH] como prefijo en el asunto, por favor).

2
src/documentation/content/xdocs/trans/guidelines.xml
View File

@ -80,7 +80,7 @@
</p>
<p>
Submitting translations is simple, you follow the same
<link href="/getinvolved/index.html">instructions</link> as you would for submitting a code patch.
<link href="/guidelines.html">instructions</link> as you would for submitting a code patch.
Remeber to always generate patchs in diff -u format preserving the context relative to the jakarta-poi directory. Also remember
to submit any new files in a directory preserving archive format. Never post these to the list, always use
<link href="http://issues.apache.org/bugzilla/buglist.cgi?product=POI&amp;short_desc=%5BPATCH%5D&amp;short_desc_type=allwordssubstr">Bugzilla</link>

2
src/documentation/skinconf.xml
View File

@ -114,7 +114,7 @@ be used to configure the chosen Forrest skin.
<host-logo></host-logo>
<!-- The following are used to construct a copyright statement -->
<year>2002-2009</year>
<year>2002-2010</year>
<vendor>The Apache Software Foundation</vendor>
<!-- Some skins use this to form a 'breadcrumb trail' of links. If you don't