DJ Delorie wrote:
>> I still have to decide, where to start. An overview? A getting
>> started? A HOWTO? A table of contents to be filled?
>
> Based on what kinds of questions I tend to answer in irc and email, I
> think the relative priority should be:
>
> * Introductory tutorials that demonstrate the most common flows,
IMHO, this should not be plural. That is, a getting started should
decide for one work-flow and stick with it. A reader should not feel
the necessity to decide between options before he/she can grasp the
consequences. On the other hand, the flexibilities should not be
completely hidden, either.
How about this:
Redo the toy task of the getting-started with different work-flows.
> showing off the most current and
I'd say, tutorials are not a place to show off, but to teach.
(Mayby I am overly picky with words...)
> newbie-friendly ways of using the tools.
^^^^^^^^^^^^^^^
Here comes the hard part: "What exactly is newbie-friendly?"
Is it a step-by-step walk through a minimum manual set-up of a project?
Or is a scripted set-up wich results in a full fledged project dir
complete with local configs and makefiles? Both have their pros and cons.
> * How-to's for tasks which are less common, showing off the "toolkit"
> features.
I like to imagine this in the form of show-casing real world projects
which demonstrate how specific tasks can be achieved. Ideally, the
show-cases would include source files at different stages. Topics for
advanced use:
* drawing symbols
* creating footprints manually on PCB canvas
* creating footprints with the various generators
* scripted printing
* use of makefiles
* a self contained project dir
* simple hierarchy
* hierarchy with sub sheets used several times
* layout with repetative portions
* source control with git
Additional items:
* A vademecum of keyboard accels, actions, file formats and important
command line options. This is kind of a reference manual light.
* the history of geda, gaf, pcb, etc.
* getting started with simulation (unfortunately, I am a complete noob
for this)
> * Replacements for the reference manuals.
Reference manuals should be comprehensive, accurate and reflect the
status of a specific version. Overall style and readability are
less a concern. This calls for tight coupling to the source and
inclusion in the make tool chain.
The concept of collaborative online editing does not mix well
with such a scripted approach. It is part of the source and
should be treated as such.
> * Internals docs for new developers.
This is clearly a task for core developers and way beyond
the scope of what I intend to start.
Anyway, I wouldn't sort the priority of these documents in any
specific order. All of them are vital for the project -- each
in a different way.
---<)kaimartin(>---
--
Kai-Martin Knaak
Email: k...@familieknaak.de
http://pool.sks-keyservers.net:11371/pks/lookup?search=0x6C0B9F53
Moderation of geda-user seems to be lifted, lately. I am still
unhappy with it. Why? Because it is completely nontransparent.
_______________________________________________
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
