> IMHO, this should not be plural. That is, a getting started should > decide for one work-flow and stick with it.
As John points out, there's more to geda than making circuit boards. So, tutorials for schematics->pcb, schematics->sim, verilog->sim, etc. Then, within each case, beginner vs advanced, like one schematic to a two-layer board, then multiple schematics, then heirarchical to many-layer with BOM and gerber, etc. > > 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...) I meant, for example, using PCB's importer instead of gsch2pcb, or snapshots of the GTK interface instead of the ancient Xaw one. > > newbie-friendly ways of using the tools. > ^^^^^^^^^^^^^^^ > Here comes the hard part: "What exactly is newbie-friendly?" To me, this means "if you've never used gEDA before". I like to assume that anyone attempting to do EDA already has some electronics background and is familiar with their computer's OS, but hasn't touched EDA yet. The kinds of advanced techniques we talk about in the geda-user list is not something I want to expose a new user to until they understand the basic functionality of the toolchain as a whole. > 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. I like to use toy designs that demonstrate the techniques, and leave it up to the user to apply those techniques to more complex designs. See http://www.delorie.com/pcb/docs/gs/gs.html#Your-First-Board At this stage, the tutorial should be end-to-end so that the user gets a sense of accomplishing something without the frustration of the big learning curve. > > * 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. IMHO it needs more than just a source extraction. There's some overview information that needs to be in there - the WHY of everything, not just the WHAT. > > * Internals docs for new developers. > > This is clearly a task for core developers and way beyond > the scope of what I intend to start. Yup. Don't worry about it, just keep in mind that it'll be out there at some point. _______________________________________________ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
