Documentation Team

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
27 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Documentation Team

Casey Ransberger-2
Looking at 


I don't see a documentation team listed. Has it been disbanded?

If the documentation team has been disbanded, I would like to offer to lead a new documentation team (in which case I would draft up a proposal with expected deliverables, etc.) If the documentation team has not been disbanded, I would like to join it.



Reply | Threaded
Open this post in threaded view
|

Re: Documentation Team

Andreas.Raab
On 4/19/2010 1:24 PM, Casey Ransberger wrote:

> Looking at
>
> http://squeak.org/Community/Teams/
>
> I don't see a documentation team listed. Has it been disbanded?
>
> If the documentation team has been disbanded, I would like to offer to
> lead a new documentation team (in which case I would draft up a proposal
> with expected deliverables, etc.) If the documentation team has not been
> disbanded, I would like to join it.

I don't think there's been much activity in a loooong time so I'd guess
it's been effectively disbanded. If you'd like to play a role in
resurrecting it please post your ideas!

Cheers,
   - Andreas


Reply | Threaded
Open this post in threaded view
|

Re: Documentation Team

Michael Haupt-3
In reply to this post by Casey Ransberger-2
Hi Casey,

with all the documentation-related blurb I posted during campaigning,
you got me started naturally. This is a very good idea. :-)

What are your plans? What form of documentation do you envision, and
what kind? How would you try to get people contribute documentation
instead of just code? What do you think about making documentation
available both in- and outside the image? Packageable?

Sorry for the many questions, but this *is* an important topic IMHO,
and I care. :-)

Best,

Michael

On Mon, Apr 19, 2010 at 10:24 PM, Casey Ransberger
<[hidden email]> wrote:
> Looking at
> http://squeak.org/Community/Teams/
> I don't see a documentation team listed. Has it been disbanded?
> If the documentation team has been disbanded, I would like to offer to lead
> a new documentation team (in which case I would draft up a proposal with
> expected deliverables, etc.) If the documentation team has not been
> disbanded, I would like to join it.

Reply | Threaded
Open this post in threaded view
|

Re: Documentation Team

Hannes Hirzel
Hello

As we now have this nice help menu I think we should make use of it.
New versions of the texts there may be easily put as an mcz file into
the inbox and show up there for people connected to the trunk. So it
will be under version control and considered to be a regular Squeak
artifact. This is for the basic documentation including hooks and
loading procedures.

Additional documentation could be done in the form of some packages on
Squeaksource which people may load on demand.

A simple reader might be used for displaying the information.  A
three-pane browser like
http://lists.squeakfoundation.org/pipermail/beginners/attachments/20100419/0ea15bf9/PastedGraphic-1.png

If somebody wants to go for immediate action: What about taking that
and using it for displaying the Terse Guide of Squeak? Maybe somebody
likes to put this into the inbox?

I think documentation _in_ the image is important. The goal of
documentation is to save time. If I for myself need several hours to
find out a procedure, the next person does not need to have the same
struggle. A few lines of text save ofther people a lot of struggle

e.g. the installation of Pier2
http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-April/148974.html


The nice thing people often forget is that any text may be selected
and executed. This is something to really make use of.
And: documentation should be loadable and unloadable like other modules.

I am willing to contribute if meaningful transactions (of
contributions) may be done within 30 minutes to 3 hours.

Best wishes

Hannes

P.S.1 I think we should revive the documentation mailing list and have
the discussion there to reduce the load on this list.

P.S. 2
Or the beginner's list might be a place as well for this as it is not
crowded and there would be "customers".  The term 'beginner' might
frighten some people who have been around for a long time. Anyhow if I
do not know how something works in a particular area I am a beginner
in that area. And the system is actually huge. In which other system
are you allowed to tweak the GUI library for example.

On 4/20/10, Michael Haupt <[hidden email]> wrote:

> Hi Casey,
>
> with all the documentation-related blurb I posted during campaigning,
> you got me started naturally. This is a very good idea. :-)
>
> What are your plans? What form of documentation do you envision, and
> what kind? How would you try to get people contribute documentation
> instead of just code? What do you think about making documentation
> available both in- and outside the image? Packageable?
>
> Sorry for the many questions, but this *is* an important topic IMHO,
> and I care. :-)
>
> Best,
>
> Michael
>
> On Mon, Apr 19, 2010 at 10:24 PM, Casey Ransberger
> <[hidden email]> wrote:
>> Looking at
>> http://squeak.org/Community/Teams/
>> I don't see a documentation team listed. Has it been disbanded?
>> If the documentation team has been disbanded, I would like to offer to
>> lead
>> a new documentation team (in which case I would draft up a proposal with
>> expected deliverables, etc.) If the documentation team has not been
>> disbanded, I would like to join it.
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Documentation Team

Bert Freudenberg
On 20.04.2010, at 17:25, Hannes Hirzel wrote:

>
> Hello
>
> As we now have this nice help menu I think we should make use of it.
> New versions of the texts there may be easily put as an mcz file into
> the inbox and show up there for people connected to the trunk. So it
> will be under version control and considered to be a regular Squeak
> artifact. This is for the basic documentation including hooks and
> loading procedures.
>
> Additional documentation could be done in the form of some packages on
> Squeaksource which people may load on demand.
>
> A simple reader might be used for displaying the information.  A
> three-pane browser like
> http://lists.squeakfoundation.org/pipermail/beginners/attachments/20100419/0ea15bf9/PastedGraphic-1.png
>
> If somebody wants to go for immediate action: What about taking that
> and using it for displaying the Terse Guide of Squeak? Maybe somebody
> likes to put this into the inbox?
>
> I think documentation _in_ the image is important. The goal of
> documentation is to save time. If I for myself need several hours to
> find out a procedure, the next person does not need to have the same
> struggle. A few lines of text save ofther people a lot of struggle
>
> e.g. the installation of Pier2
> http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-April/148974.html
>
>
> The nice thing people often forget is that any text may be selected
> and executed. This is something to really make use of.
> And: documentation should be loadable and unloadable like other modules.
>
> I am willing to contribute if meaningful transactions (of
> contributions) may be done within 30 minutes to 3 hours.
>
> Best wishes
>
> Hannes
>
> P.S.1 I think we should revive the documentation mailing list and have
> the discussion there to reduce the load on this list.
>
> P.S. 2
> Or the beginner's list might be a place as well for this as it is not
> crowded and there would be "customers".  The term 'beginner' might
> frighten some people who have been around for a long time. Anyhow if I
> do not know how something works in a particular area I am a beginner
> in that area. And the system is actually huge. In which other system
> are you allowed to tweak the GUI library for example.

IMHO discussion of documentation should happen here on squeak-dev. It concerns everyone.

The beginner's list is a place to get advice, not to discuss features or strategies.

- Bert -



Reply | Threaded
Open this post in threaded view
|

Re: Documentation Team

Hannes Hirzel
OK. That's fine for me.
Hannes

On 4/20/10, Bert Freudenberg <[hidden email]> wrote:

> On 20.04.2010, at 17:25, Hannes Hirzel wrote:
>>
>> Hello
>>
>> As we now have this nice help menu I think we should make use of it.
>> New versions of the texts there may be easily put as an mcz file into
>> the inbox and show up there for people connected to the trunk. So it
>> will be under version control and considered to be a regular Squeak
>> artifact. This is for the basic documentation including hooks and
>> loading procedures.
>>
>> Additional documentation could be done in the form of some packages on
>> Squeaksource which people may load on demand.
>>
>> A simple reader might be used for displaying the information.  A
>> three-pane browser like
>> http://lists.squeakfoundation.org/pipermail/beginners/attachments/20100419/0ea15bf9/PastedGraphic-1.png
>>
>> If somebody wants to go for immediate action: What about taking that
>> and using it for displaying the Terse Guide of Squeak? Maybe somebody
>> likes to put this into the inbox?
>>
>> I think documentation _in_ the image is important. The goal of
>> documentation is to save time. If I for myself need several hours to
>> find out a procedure, the next person does not need to have the same
>> struggle. A few lines of text save ofther people a lot of struggle
>>
>> e.g. the installation of Pier2
>> http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-April/148974.html
>>
>>
>> The nice thing people often forget is that any text may be selected
>> and executed. This is something to really make use of.
>> And: documentation should be loadable and unloadable like other modules.
>>
>> I am willing to contribute if meaningful transactions (of
>> contributions) may be done within 30 minutes to 3 hours.
>>
>> Best wishes
>>
>> Hannes
>>
>> P.S.1 I think we should revive the documentation mailing list and have
>> the discussion there to reduce the load on this list.
>>
>> P.S. 2
>> Or the beginner's list might be a place as well for this as it is not
>> crowded and there would be "customers".  The term 'beginner' might
>> frighten some people who have been around for a long time. Anyhow if I
>> do not know how something works in a particular area I am a beginner
>> in that area. And the system is actually huge. In which other system
>> are you allowed to tweak the GUI library for example.
>
> IMHO discussion of documentation should happen here on squeak-dev. It
> concerns everyone.
>
> The beginner's list is a place to get advice, not to discuss features or
> strategies.
>
> - Bert -
>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Documentation Team

Casey Ransberger-2
In reply to this post by Bert Freudenberg
+1

I don't want to silo all documentation on a "documentation team" either. To my mind the role of a docs team is to support the broader community in an effort to improve documentation, not to write it all in a vacuum. Proposal is coming.

On Tue, Apr 20, 2010 at 8:38 AM, Bert Freudenberg <[hidden email]> wrote:

IMHO discussion of documentation should happen here on squeak-dev. It concerns everyone.

The beginner's list is a place to get advice, not to discuss features or strategies.

- Bert -






Reply | Threaded
Open this post in threaded view
|

Re: Documentation Team

Michael Haupt-3
Hi Casey,

On Tue, Apr 20, 2010 at 7:59 PM, Casey Ransberger
<[hidden email]> wrote:
> I don't want to silo all documentation on a "documentation team" either. To
> my mind the role of a docs team is to support the broader community in an
> effort to improve documentation, not to write it all in a vacuum.

that is going to be hard, but you can count at least me in. :-)

> Proposal is coming.

Staying tuned,

Michael

Reply | Threaded
Open this post in threaded view
|

Re: Documentation Team

Hannes Hirzel
In reply to this post by Casey Ransberger-2
On 4/19/10, Casey Ransberger <[hidden email]> wrote:

> Looking at
>
> http://squeak.org/Community/Teams/
>
> I don't see a documentation team listed. Has it been disbanded?
>
> If the documentation team has been disbanded, I would like to offer to lead
> a new documentation team (in which case I would draft up a proposal with
> expected deliverables, etc.) If the documentation team has not been
> disbanded, I would like to join it.


Casey,

you started this thread in April and there was quite some interest of
people contributing but for lack of time or maybe lack of an
appropriate approach only few things have happened. There are notable
exceptions one. We have a help browser in the trunk by now and a good
example of a documentation (Webclient) as well as one (1) tutorial
about reading XML files.

Jecel Assumpcao Jr. suggest that the should continue this effort
http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-August/152703.html.

Casey Ransberger writes that he needs to find time.


We are facing challenges here.

1) How do we include the help of people with maybe time as little as 1
hour per month (but who have a huge Smalltalk knowhow, e.g. R.J.)

2) Where should we start?

My answers
1) Have two persons who have commit access to the trunk who the other
commiters trust who will commit changes. It is very motivating if I
write a class comment for example and one day later it is in all my
trunk images I update.

2a) I would say it should be customer driven. We should go to the
beginners list and ask them what they want to know and try to work
there.
2b) I did some querying about which classes need comments. More
information available on request.

--Hannes

Reply | Threaded
Open this post in threaded view
|

Re: Documentation Team

Michael Haupt-3
Hi,

remembering that I had volunteered to contribute to documentation,
I've had a brief off-list exchange with Casey about this.
Interestingly, we both have in common that we like to have reasonably
sized work items that can be ticked off in predictable time frames.
Probably more people feel like this.

The questions you ask, and the solutions you propose make sense to me.

On Wed, Aug 25, 2010 at 8:20 AM, Hannes Hirzel <[hidden email]> wrote:

> 1) How do we include the help of people with maybe time as little as 1
> hour per month (but who have a huge Smalltalk knowhow, e.g. R.J.)
>
> 2) Where should we start?
>
> My answers
> 1) Have two persons who have commit access to the trunk who the other
> commiters trust who will commit changes. It is very motivating if I
> write a class comment for example and one day later it is in all my
> trunk images I update.

Why two? Class comments and documentation are trunk code, so trunk
developers should be able and entitled to contribute them. Everyone
interested can contribute via the inbox.

I think that the more complicated task is to get started (your
question 2). What needs to be documented? Who does it? How can this be
organised in an unobtrusive way?

What? - See below.
Who? - All of us.
How? - See below.

> 2a) I would say it should be customer driven. We should go to the
> beginners list and ask them what they want to know and try to work
> there.
> 2b) I did some querying about which classes need comments. More
> information available on request.

Mantis, Mantis, Mantis. Documentation issues should be considered
"bugs" (in the sense that they bug people). Requests for documentation
improvements / additions could be posted in a dedicated bug category.
I would expect particularly class comment issues to be about the size
that I alluded to above (reasonably sized, tickable-off in predictable
time - say, an hour a week, as you mentioned).

How about asking people to submit requests for documentation via
Mantis? Point people on the newbies list to that and have them ask for
improvement.

How about turning your "more information" into some Mantis issues right away?

Best,

Michael

Reply | Threaded
Open this post in threaded view
|

Re: Documentation Team

Hannes Hirzel
On 8/25/10, Michael Haupt <[hidden email]> wrote:
> Hi,
>
> remembering that I had volunteered to contribute to documentation,
> I've had a brief off-list exchange with Casey about this.
> Interestingly, we both have in common that we like to have reasonably
> sized work items that can be ticked off in predictable time frames.
> Probably more people feel like this.
>
> The questions you ask, and the solutions you propose make sense to me.

OK, fine.

> On Wed, Aug 25, 2010 at 8:20 AM, Hannes Hirzel <[hidden email]>
> wrote:
>> 1) How do we include the help of people with maybe time as little as 1
>> hour per month (but who have a huge Smalltalk knowhow, e.g. R.J.)
>>
>> 2) Where should we start?
>>
>> My answers
>> 1) Have two persons who have commit access to the trunk who the other
>> commiters trust who will commit changes. It is very motivating if I
>> write a class comment for example and one day later it is in all my
>> trunk images I update.
>
> Why two? Class comments and documentation are trunk code, so trunk
> developers should be able and entitled to contribute them. Everyone
> interested can contribute via the inbox.

OK, thank you for reminding us of this.
You are right,
nobody holds us back approaching one of the commiters we see active
and ask him to commit a 'class comment' only change for us.


> I think that the more complicated task is to get started (your
> question 2). What needs to be documented? Who does it? How can this be
> organised in an unobtrusive way?
>
> What? - See below.
> Who? - All of us.
> How? - See below.
>
>> 2a) I would say it should be customer driven. We should go to the
>> beginners list and ask them what they want to know and try to work
>> there.
>> 2b) I did some querying about which classes need comments. More
>> information available on request.
>
> Mantis, Mantis, Mantis. Documentation issues should be considered
> "bugs" (in the sense that they bug people).

I think this is the key
  "Missing documentation is a defect / bug".


 Requests for documentation
> improvements / additions could be posted in a dedicated bug category.

We have to check if  there a is a  category for tag a ticket as
'Documentation' in Mantis?
If not we have to get it included there.


> I would expect particularly class comment issues to be about the size
> that I alluded to above (reasonably sized, tickable-off in predictable
> time - say, an hour a week, as you mentioned).
>
> How about asking people to submit requests for documentation via
> Mantis? Point people on the newbies list to that and have them ask for
> improvement.

I second this idea.

>
> How about turning your "more information" into some Mantis issues right
> away?

Fine, thank you for the suggestion. I will file tickets in the
upcoming weeks if people agree that we should go this road for
documentation requests.

To summarize: We have to get documentation tasks into "chewable
chunks". We have to work "customer oriented". This means to do things
real people actually using Squeak 4.1 want to know.


Best wishes

Hannes

Reply | Threaded
Open this post in threaded view
|

Re: Documentation Team

Michael Haupt-3
Hi Hannes,

On Wed, Aug 25, 2010 at 12:07 PM, Hannes Hirzel <[hidden email]> wrote:
> nobody holds us back approaching one of the commiters we see active
> and ask him to commit a 'class comment' only change for us.

... or everyone can do it themselves and push it to the inbox. It will
be noticed.

>  "Missing documentation is a defect / bug".
> ...
> We have to check if  there a is a  category for tag a ticket as
> 'Documentation' in Mantis?
> If not we have to get it included there.

If that is easy to do, it would *really* be good to have such a tag/category.

> To summarize: We have to get documentation tasks into "chewable
> chunks". We have to work "customer oriented". This means to do things
> real people actually using Squeak 4.1 want to know.

Yup.

Best,

Michael

Reply | Threaded
Open this post in threaded view
|

Re: Documentation Team

Casey Ransberger-2
In reply to this post by Hannes Hirzel
I've had luck getting class comments in via inbox; the core devs seem quite happy to check documentation into the trunk.

On Aug 24, 2010, at 11:20 PM, Hannes Hirzel <[hidden email]> wrote:

> On 4/19/10, Casey Ransberger <[hidden email]> wrote:
>> Looking at
>>
>> http://squeak.org/Community/Teams/
>>
>> I don't see a documentation team listed. Has it been disbanded?
>>
>> If the documentation team has been disbanded, I would like to offer to lead
>> a new documentation team (in which case I would draft up a proposal with
>> expected deliverables, etc.) If the documentation team has not been
>> disbanded, I would like to join it.
>
>
> Casey,
>
> you started this thread in April and there was quite some interest of
> people contributing but for lack of time or maybe lack of an
> appropriate approach only few things have happened. There are notable
> exceptions one. We have a help browser in the trunk by now and a good
> example of a documentation (Webclient) as well as one (1) tutorial
> about reading XML files.
>
> Jecel Assumpcao Jr. suggest that the should continue this effort
> http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-August/152703.html.
>
> Casey Ransberger writes that he needs to find time.
>
>
> We are facing challenges here.
>
> 1) How do we include the help of people with maybe time as little as 1
> hour per month (but who have a huge Smalltalk knowhow, e.g. R.J.)
>
> 2) Where should we start?
>
> My answers
> 1) Have two persons who have commit access to the trunk who the other
> commiters trust who will commit changes. It is very motivating if I
> write a class comment for example and one day later it is in all my
> trunk images I update.
>
> 2a) I would say it should be customer driven. We should go to the
> beginners list and ask them what they want to know and try to work
> there.
> 2b) I did some querying about which classes need comments. More
> information available on request.
>
> --Hannes
>

Reply | Threaded
Open this post in threaded view
|

Re: Documentation Team

Michael Haupt-3
Hi,

On Wed, Aug 25, 2010 at 4:33 PM, Casey Ransberger
<[hidden email]> wrote:
> I've had luck getting class comments in via inbox; the core devs seem quite happy to check documentation into the trunk.

I'm a core dev myself for some reason, so there's really no major obstacle. :-)

Best,

Michael

Reply | Threaded
Open this post in threaded view
|

Re: Documentation Team

Nicolas Cellier
For sure, the responsibility of documentation team cannot be to write
each and every comment...
It would be to
- collect good practices (what to put or not in a comment),
- encourage a uniform style (maybe by providing good examples and
doing some marketing),
- polish a bit contributions from others (or kindly ask them to)
toward this goal

Only my POV...

Nicolas

2010/8/25 Michael Haupt <[hidden email]>:

> Hi,
>
> On Wed, Aug 25, 2010 at 4:33 PM, Casey Ransberger
> <[hidden email]> wrote:
>> I've had luck getting class comments in via inbox; the core devs seem quite happy to check documentation into the trunk.
>
> I'm a core dev myself for some reason, so there's really no major obstacle. :-)
>
> Best,
>
> Michael
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Documentation Team

Michael Haupt-3
Hi Nicolas,

On Wed, Aug 25, 2010 at 10:37 PM, Nicolas Cellier
<[hidden email]> wrote:
> For sure, the responsibility of documentation team cannot be to write
> each and every comment...
> It would be to
> - collect good practices (what to put or not in a comment),
> - encourage a uniform style (maybe by providing good examples and
> doing some marketing),
> - polish a bit contributions from others (or kindly ask them to)
> toward this goal

you are right, of course, but someone has to make a start, right?

Best,

Michael

Reply | Threaded
Open this post in threaded view
|

Re: Documentation Team

Jecel Assumpcao Jr
I would like to thank Michael Haupt, Nicolas Cellier, Hannes Hirzel and
Casey Ransberger for investing their time in this discussion. I agree
with what has been said so far, but perhaps we should step back a bit
and try to define what will be the scope of the documentation and how it
will be presented.

About the who, I fully agree this will be a job for everybody and not
just the Documentation Team. I see a team like this as a group that will
create the necessary infrastructure and might even act as editors, but
the authors are a separate group (it will be great if people want to be
a part of both, of course).

Of course we have methods comments and class comments, but I think there
is no limit to the kind of in-image documentation we can have. And if
the trend is towards a smaller kernel with loadable stuff, the bulk of
this documentation could be in the form of loadable packages. Using the
same tools and proceedures as for evolving the code is certainly a good
option (though this might require extending those tools a bit).

One important feature for the documentation is to make it more easily
available outside of Squeak. I don't like to write the same thing twice,
but imagine that we could create a doc.squeak.org site running a fully
loaded image and automatically exporting all the documentation in a form
that people and web crawlers can use.

These are just some ideas to keep the ball rolling.

-- Jecel


Reply | Threaded
Open this post in threaded view
|

Re: Documentation Team

Casey Ransberger-2
In reply to this post by Michael Haupt-3
+1 to the docs site.

I'd attack it by hooking into the help system from Seaside, and generate search engine friendly URLs based on the topic.

Help system can already give us a quick and dirty "API reference" in addition to the hand written docs, and I'd want to arrange for that to be visible from the web as well.

That said, I think the web facing docs are a lower priority than gettin some good documentation written.

A web interface is a chunk of work, and I'd (or someone anyway) need to find the time to get it done. I'm confident that I could get it done if I had an infinite supply of monkeys, virtual machines, and time, however.

(Seriously, shouldn't be too bad, but these things always take at least twice as long as one thinks they will...)

On Aug 25, 2010, at 4:08 PM, "Jecel Assumpcao Jr." <[hidden email]> wrote:

> I would like to thank Michael Haupt, Nicolas Cellier, Hannes Hirzel and
> Casey Ransberger for investing their time in this discussion. I agree
> with what has been said so far, but perhaps we should step back a bit
> and try to define what will be the scope of the documentation and how it
> will be presented.
>
> About the who, I fully agree this will be a job for everybody and not
> just the Documentation Team. I see a team like this as a group that will
> create the necessary infrastructure and might even act as editors, but
> the authors are a separate group (it will be great if people want to be
> a part of both, of course).
>
> Of course we have methods comments and class comments, but I think there
> is no limit to the kind of in-image documentation we can have. And if
> the trend is towards a smaller kernel with loadable stuff, the bulk of
> this documentation could be in the form of loadable packages. Using the
> same tools and proceedures as for evolving the code is certainly a good
> option (though this might require extending those tools a bit).
>
> One important feature for the documentation is to make it more easily
> available outside of Squeak. I don't like to write the same thing twice,
> but imagine that we could create a doc.squeak.org site running a fully
> loaded image and automatically exporting all the documentation in a form
> that people and web crawlers can use.
>
> These are just some ideas to keep the ball rolling.
>
> -- Jecel
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Documentation Team

Hannes Hirzel
On 8/26/10, Casey Ransberger <[hidden email]> wrote:
....

CURRENT ACTION FOCUS
>
> That said, I think the web facing docs are a lower priority than gettin some
> good documentation written.
>
I agree with the priority setting. We need to produce more
documentation _within_ the image.

And as the tool to stay organised we have chosen Mantis.

Generating a web version of it (something like Javadoc) - I am pretty
sure we will find somebody to do it. Similar things have been done in
the past.

The challenge is actually writing documentation. The fact that it has
not been done for a long time shows that it is not easy.

--Hannes

Reply | Threaded
Open this post in threaded view
|

Re: Documentation Team

Tobias Pape

Am 2010-08-26 um 07:26 schrieb Hannes Hirzel:

> On 8/26/10, Casey Ransberger <[hidden email]> wrote:
> ....
>
> CURRENT ACTION FOCUS
>>
>> That said, I think the web facing docs are a lower priority than gettin some
>> good documentation written.
>>
> I agree with the priority setting. We need to produce more
> documentation _within_ the image.
>
> And as the tool to stay organised we have chosen Mantis.
>
> Generating a web version of it (something like Javadoc) - I am pretty
> sure we will find somebody to do it. Similar things have been done in
> the past.


Reading that, can we interface http://soek.goodies.st/ somehow?

so long,
        -Tobias
12