bloritsch 2002/12/19 22:42:30
Modified: src/proposal/avalon5 discussion-points.txt
Added: src/proposal/avalon5 site-planning.txt
Log:
initial scratchings for site reorg thoughts
Revision Changes Path
1.3 +38 -2 jakarta-avalon/src/proposal/avalon5/discussion-points.txt
Index: discussion-points.txt
===================================================================
RCS file:
/home/cvs/jakarta-avalon/src/proposal/avalon5/discussion-points.txt,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- discussion-points.txt 17 Dec 2002 13:07:17 -0000 1.2
+++ discussion-points.txt 20 Dec 2002 06:42:30 -0000 1.3
@@ -27,7 +27,11 @@
Telivi, and we need further communication to
figure out what is the best solution.
PRO:
+ bloritsch - It has the appeal of synergy with other
+ communities.
CON:
+ bloritsch - I think that synergy comes at too high
+ a price for Avalon's architecture.
pdonald - Nah. For the sharing of one interface
it does not seem useful to couple the projects.
Commons also passes down objects which is not a
@@ -50,7 +54,15 @@
PRO:
bloritsch - We are in desparate need of a unified
and simple build architecture. IMO, Maven is
- the best choice we have available.
+ the best choice we have available. Let's
+ simplify. Speed is only part of the issue here.
+ We need to be able to manage project dependencies
+ properly, and Maven's repository is a good
+ solution. We can treat each individual project
+ separately for the time being, so there is no
+ heirarchy to worry about. When Maven does
+ support it, and I think they will, we can
+ consolidate things again.
pdonald - I am using maven to build the site for
all the stuff I am moving out of Avalon. It is
absolutely fantastic. There is a few hickups
@@ -115,7 +127,7 @@
We are currently our own entity. We are not
a Jakarta project any more. I would suggest
the mailing lists (in addition to
- [EMAIL PROTECTED]): developers@, users@,
+ [EMAIL PROTECTED]): dev@, users@,
cvs@, and possibly general@ and [EMAIL PROTECTED]
PRO:
bloritsch - It would help establish the
@@ -140,3 +152,27 @@
that it has about.
CON:
+-----------------------------------------------
+
+Topic: Should we remove unused sets of code?
+Explanation:
+ Excalibur is rife with obsolete, competing,
+ and confusing stuff. Also mixed in there are
+ some *really* useful gold nuggets. By getting
+ rid of the failed experiments, we can focus our
+ energies and web site on what is good.
+PRO:
+ bloritsch - For competing technologies, they
+ should be merged back into the parent project
+ they came out of. Nine times out of ten,
+ the only maintainers and developers for those
+ projects support the parent project. We
+ should also archive and remove all the CVS
+ stuff for our deprecated packages. We aren't
+ maintaining them any more--and they are still
+ draining energies (of users, etc.). It will
+ help clean the slate.
+CON:
+ bloritsch - What projects are we removing? It
+ is a potential sticking point, and we still
+ need a copy of the old code.
\ No newline at end of file
1.1 jakarta-avalon/src/proposal/avalon5/site-planning.txt
Index: site-planning.txt
===================================================================
A V A L O N W E B S I T E
Plan for Redesign
The current Avalon web site (http://jakarta.apache.org/avalon/)
contains alot of duplicate information, and no real design from a
users perspective. The site would benefit greatly from a redesign.
By redesign, I am not referring to the style of the pages but its
content.
Because Avalon has become a top level project, and we have a
fresh web space available to us, we need to look at makeing the
site useable. For instance, hitting the user with all the sub
projects isn't really a good idea. It's like going to a high class
restaurant and they slap a huge piece of beef on your plate--no
appetizers, salad, or anything else to cleanse the palate.
We have several types of information to keep track of on the
site. First and formost should be news and current events. Its a
nice way to get users acclamated and maybe even excited about what
is going on. We should also have a section that describes the PMC
and the Avalon Charter/By-Laws for those who are interested. We
need a quick summary of what Avalon is, and what it is not. We might
want to devote a couple pages to that topic. Lastly, we should
look at putting up the actual project documentation. The guides are
good, but they should be associated with a topic.
We need to follow a few general rules of thumb. All important
information should be within the first three pages of navigation (with
the exception of the API docs). Our URI space should make sense, and
be consistent throughout the site. For example, if the user knows that
http://avalon.apache.org/phoenix/api/ gives him the JavaDocs, then
the same should apply for http://avalon.apache.org/framework/api/.
The sub-sub-sub project thing is confusing at best. We need to find
a better way to associate our technologies. Lastly, we need a
developer's corner to address CVS access, coding standards, and other
relevant information about actively contributing.
- o -
NEWS AND ANNOUNCMENTS
Every website I go to that provides products and projects and I find
useful greets you with the current happenings of the project. Things
that are exciting, and indirectly impact the project should go here.
Examples are releases, news about other projects using Avalon, and
of course outside news that has an impact on our community.
PMC AND ADMINISTRATIVA
Any way you slice it, we need to put our charter and bylaws on the
site. We should also put up some docs that describe the *intent* of
the words in the more legalese docs.
GUIDES
Our guides are detailed instructions about different aspects of Avalon.
We might want to look at merging them into one super guide, something
that can be a reference for the shelf.
Another alternative is to break up the documentation into the following
sub sections: How-To, Why (background theory), FAQ, TODO, and Changes.
PROJECT
We should only have one project in the future.
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
