Hi Jeffrey,

Thanks for starting this thread. I'm wondering if a good way to think  
about how to organize the documentation is to map out a workflow.

Where does the person get started?
Right now, I think the 2 most obvious entry points for developers  
are: "Get Involed" page and the "Developers Wiki Area".

http://chandlerproject.org/getinvolved
http://chandlerproject.org/Developers/WebHome

The "Get Involved" page really just points you to the "Developers  
Wiki Area", if you're interested in development work.

If the "Developers Wiki Area" is still the starting point, then  
that's really where we should provide the context necessary for  
understanding:

1. Difference between Desktop + Server
2. Difference between Desktop 1.0 and 2.0
3. Technologies used for each: Desktop + Server

If our goal is still: Get people oriented and set up to start playing  
around with the code as quickly as possible. What other things should  
be extra accessible?
e.g.
- Downloading 1.0 app and downloading the source and building it?  
(for both 1.0 and 2.0).
- Tutorials? Development Tools?

I guess my question is: Does the Desktop 2.0 documentation include  
this stuff or is it more analogous to the "Reference Material"  
portion of the 1.0 documentation?

(I imagine that the "Reference Material" portion of the Chandler  
Desktop column of the "Developers Wiki Area" homepage can be shuttled  
off to a separate page dedicated to Desktop 1.0 documentation?)

I think once we have the Developers "Starting Point" ironed out, then  
we can figure out how to link to it from other places like the  
landing page, wiki homepage, "Get Involved", etc.

If you or Grant can get the scaffolding up for a "Developers Starting  
Point", then we could ask people on the list to provide input?

Best,
Mimi

On Feb 18, 2009, at 3:43 PM, Jeffrey Harris wrote:

> Hi Folks,
>
> It's time to start publicizing the chandler2 codebase to encourage
> people to hack on it.  That code doesn't yet have anything end-user
> useful, but it's the future of development.
>
> I've set up http://chandler2.osafoundation.org/ to show the
> documentation Grant and I have been working on, and in the next week
> we'll do a blog post.
>
> How else should we update our documents?  The wiki has all sorts of
> information that's of varying levels of accuracy for chandler1,  
> usually
> less accurate for chandler2.
>
> I think we should:
>
> - Create a chandler2 wiki page, explaining how chandler2 differs from
> chandler1, and what broad features are the same (still Python, still
> cross platform, etc.).
> - Add a paragraph at the top of
> http://chandlerproject.org/Developers/WebHome explaining that that  
> page
> applies to chandler1, developers looking to hack should look at  
> chandler2
> - Add some kind of explanation (probably a paragraph at the top) of
> http://chandlerproject.org/wikihome, since we link directly there from
> the chandlerproject.org landing page
> - Add a chandler2 link to the landing page sidebar
>
> How does that strike folks?
>
> Sincerely,
> Jeffrey
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "chandler-dev" mailing list
> http://lists.osafoundation.org/mailman/listinfo/chandler-dev

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev

Reply via email to