James,

This looks more like about $20, but I'm not complaining. Your thoughts 
mirror mine in many ways. #4 is a very good idea. Even just a list of 
what is needed. Folks could add to a documentation wishlist, and then 
anyone who thought he or she could tackle an item could just do it.

I'm glad that people are finally responding to this thread. I was 
beginning to think that I was on my own...

Chas.

James Matlik wrote:
> Hello Charles,
> 
> This is good news.  I'm sorry I didn't see your initial email going out, 
> but I would guess it is better late than never.  I think the first thing 
> that needs to be done is to clearly define what is to be documented in 
> the wiki and where.  Here is my 2 cents:
> 
>    1. There should be a page linked to the wiki's main page providing
>       marketing style information.  This could be a kind of "About Lift"
>       page on steroids.  What makes Lift novel?  What features does it
>       provide that simplify the state of the art in web development? 
>       How easily can the technology be integrated with legacy
>       deployments?  What design goals does Lift strive for and why? 
>       Does Lift have a viable future?  What is Lift's stance on KIR
>       support?  Once an official release is made public, will bug fixes
>       be applied to that version going forward and for how long?  How
>       stable is the API?
>    2. A brief description of the Lift culture could be beneficial; a
>       kind of "welcome to the party, this is how we roll" for the
>       uninitiated (I'm still figuring it out). 
>    3. Make a clearly defined section for people developing applications
>       with Lift.  Give a 100ft view of the code/compile/deploy/test
>       development cycle, then delve into the tools that make this cycle
>       simpler.  Provide the basics on Maven, what it is, what it does
>       for Lift, and the commands of interest for Lift development. 
>       Describe how Maven is not required for the Maven adverse, and
>       provide instructions on how to proceed without Maven (maybe an
>       opportunity for sbaz?).  Up-to-date HowTo documents on standing up
>       different editors (Nebeans, Eclipse, Idea, etc.) are important.
>       How should Lift be deployed?  What are the required dependencies? 
>       Is it reasonable to simply use Maven's jetty:run target for a
>       production deployment?  What are the common configuration settings
>       for various servlet containers for development vs. production
>       deployments.  What architectures should be used for scaling out
>       deployments for redundancy and performance (serialization,
>       Terracotta, load balancing, etc.)?  Development, deployment and
>       KIR overview for those familiar with Rails but not with Java.
>    4. A documentation TODO list for people to contribute.
>    5. Are there any best practices?  Some good topics could be I18N, how
>       to avoid introducing security vulnerabilities like cross site
>       scripting or SQL injection attacks, how best to leverage templates
>       for CMS-like systems with very large numbers of unique pages vs.
>       applications with a relatively short list of screens, security and
>       performance tuning.
>    6. There needs to be a very clear division between documentation for
>       public reference and works in progress/new feature collaboration
>       that would only confuse people. 
>    7. There is a lot of good example code in the lift demo app.  It
>       might be nice to provide some supplemental annotated documentation
>       in the wiki (a lot of people don't turn to the code by default). 
>       This could be a kind of "recipes for Lift" section that could
>       contain all kinds of examples including those in the demo app.  As
>       people contribute creative solutions or solutions to common
>       problems, they could eventually be pulled into the demo app.
> 
> I'm sure some of this already exists on the wiki, but it would nice if 
> the navigation made it easier to find. 
> 
> As for registering with the wiki, could OpenID be supported for the wiki 
> account?  I'm seriously tired of creating new accounts all the time with 
> the same unchanging handful of passwords that I regularly have to cycle 
> through when accessing my account.  I'd like to see OpenID implemented 
> everywhere.
> 
> On Tue, Apr 21, 2009 at 3:38 PM, Charles F. Munat <[email protected] 
> <mailto:[email protected]>> wrote:
> 
> 
>     I am charged with coming up with a site map/information architecture for
>     our hopefully-soon-to-be-updated wiki.
> 
>     What would most benefit you on a documentation wiki? What sorts of
>     things are you having the most problems with?
> 
>     Please submit suggestions for a wiki outline, as well as any other ideas
>     you have. For example, ideas on wiki structure are welcome. You could
>     even suggest your own outline.
> 
>     Please participate! Yes, you, lurker! We want to know what you need.
> 
>     I'll collect all the ideas this weekend, consolidate them, and present a
>     suggested outline (road map) for the documentation wiki.
> 
>     Thanks!
> 
>     Yes! If you are reading this, then I am talking to you. Speak up.
> 
>     Chas.
> 
> 
> 
> 
> > 

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to