Which would be a copyright violation we can’t condone just copy and pasting content and then expect people to respect the GPL copyright on the source code in kind. So it quickly becomes not easy and requires obtaining permission per content you copy over.
The problem with a wiki is the need for moderation and active management. Spam bots hit wikis incredibly easily. Content quickly goes stale. Nobody on the dev team has time and we would need quite some step up from the community before we would consider it officially. Alternatively the community can start their own.
I’m happy and willing to wait to see what @craftyjon and Co. have to offer, although I don’t think he really needs another hat to wear.
If it is good… Great.
If someone thinks something can be improved upon… he is only a private mail away.
If somethings are missing… there are FAQ wikis to fill in gaps and take beyond the basics.
What we’re working on is a very basic text tutorial. We are not working on videos, wikis, advanced tutorials, etc. I think it would be great if others in the community wanted to do more of those things, though.
I just keep stacking them as long as they don’t all fall off my head
In my worthless opinion, “design by committee” means that the committee decides everything. That would be too much work. What I see an assembly of contributions. I may contribute to a few portions but have no input to most other parts. If I write a portion, a moderator may discard it or accept it or edit it. Nobody here will be Hemmingway or Dickens…
Then, once this is all complete we will need a “Getting Stopped Guide.” Every car and bicycle needs brakes, right?
Great discussion, looks like things are heading to a healthy outcome, even if that is “nothing, for now”. For those looking to contribute, I thought this might help guide. This is the internal reference I created for my team of EEs to get started with KiCad. Some common themes are reflected:
Here are the recommended resources for getting started with KiCad.
The best introduction is probably the one by Rene on the forum. Rene is a very regular contributor with a heap of practical knowledge. If you follow his guide from top to bottom you’ll get a good overview and a bit of practice with the important elements. Tutorial: Introduction to PCB design with KiCad version 5.1 (Getting Started)
I have to mention Chris Gammell, who’s also a very prolific community member and does a lot of KiCad education. His “Getting to Blinky” course is the best example, but it’s really for people new to electronics, not just KiCad, so may not be right for you. But it is visual, which is great for learning software, so for reference here it is: https://contextualelectronics.com/courses/getting-to-blinky-5-0/
There’s a surprising lack of “KiCad for those that know Altium” introductions out there. For me the big cognitive shifts to make are:
a. “selecting” a item is not a big deal - just hover and hit the shortcut key; and,
b. symbols and footprints are in separate libraries; and
c. you do not have to pick a part before you drop a symbol on the schematic! To me this is the separate content from formatting philosophy that systems like LaTeX and Confluence and Write! and CSS have leveraged. It can be really powerful, so try not to fight it from the beginning.
Once you know the basics, our KiCAD Workflow is a powerful collection of conventions and checklists that constrain the dizzying freedom that the tool offers into some processes that work for us. This is particularly true around BOM management - the tools let you do pretty much whatever you want, so we’ve narrowed that down into a system that limits some of the chaos and inefficiency that comes with so much freedom.
Note that v5 was a big step forward for KiCad - if you’re following guides online, make sure they’re for v5. v6 is due out later this year and it looks like it’ll be a ripper. The forum and IRC channels are very helpful, and the developers are amazingly responsive. The software is very extensible via Python, the file format is plain text, and so there’s a good chance that if something needs improving, it will be, one way or the other.
One of our guys ended up putting together a ~90 minute presentation of him walking through the creation of a fictional design. It was excellent, and accelerates learning all those little tricks of usage and potential frustrations that are hard to convey in text. But alas, we didn’t record it. And video is so hard to correct/update/maintain/search/expand/do anything other than linear consumption.
I’m going to make a last attempt to updating the “Getting Started with KiCad V6.0” in time for the official V6 release.
First step I’ve taken is ordering a new PC & bigger monitor.
They are due to be delivered Friday 2021-12-17.
This was needed because I made an error with my current PC and made the system partition too small, so I could not install the complete development environment for compiling the documentation.
I’ve also invited a friend to get some help with dinner, beer and git to fill in the last gaps in my knowledge with Git.
Screenshots are easy, texts are doable.
I would like to get some help.
The best help would be from total beginners with KiCad, because they are in the best position to point out flaws and omissions in what is needed for “Getting Started in KiCad”. I hope to have something ready for proofreading and tryout in 2 or 3 weeks.
Having a Wiki for KiCad would be nice.
Currently there are a lot of entries in the FAQ, and there is much more info there than in an “average FAQ”.
The format of the FAQ does not lend itself well for making an index or editing. I’ve written an FAQ article myself, and I’m afraid that if I make a typo in a link of a previously posted screenshot, that the screenshot is lost.
A Wiki has a much more robust workflow with integrated GIT, indexes, tables and a lot of other goodies.
The “Getting started in KiCad” guide should be a relatively lineair guide, and a pdf format (or a web page) works well. Converting the FAQ to Wiki articles would probably increase their usability. Adding that Wiki to the KiCad website itself, instead of to this forum is probably also an improvement.
One has to figure out where to host said Wiki. I just checked to verify my colander-like memory and GitLab does have a Wiki engine. I don’t know how user friendly it is for both viewers and maintainers, but that should/could be an option to explore when choosing a Wiki hosting site.
I’m a newbie. Never designed a PCB, never knew what a Gerber was, etc.
I am LOVING going thru the Getting Started doc.
Problem is, it is not accurate in some places, I guess it was for a previous KiCad version? Good news, it’s not so inaccurate that I can’t figure out what I’m really supposed to click on, and where.
So I decided to edit the doc in GitLabs to update inaccuracies. I don’t know why my commits haven’t shown up in Master. Now I see a 5.1 branch. Don’t know git too well yet so I lost interest. Plus, I find it very cumbersome to edit it with the in-line editor. Maybe I am missing some tips and tricks (can’t I preview the doc live as I edit it??).
If I were to write docs I would just write/edit them in Google Docs and export as PDF or HTML. People could still collaborate and edit the original Google Doc. Much more user-friendly than the existing editing method, IMO.
And I don’t like watching videos of a detailed tutorial, would much rather slowly work my way through a well-annotated doc, like the Getting Started doc is, minus inaccuracies here and there.
The getting started guide initial draft needs to be reviewed by 2 types of newbies:
(1) Those who have never used such software before.
(2) Those who already know Eagle, Altium, etc but NOT KiKad.
So it ought to have sort of a double-structure.
I realize this is obvious but probably worth stating.
but also by other people with lots of experience and who know all the tricks.
I’d think that adding little tips and tricks through the getting started guide (for example the auto repeat and increment for adding labels while depressing [Ins] helps a lot with helping newbies who read it up to speed with KiCad and how to use it effectively. Anyone who knows such tips can add them. It is of course always some sort of balance.
So my new PC is up and running now.
I made a fresh fork of the KiCad documentation on gitlab, cloned it my own PC.
I also got some help from a friend who helped me with ironing out some GIT issues (and I only gave him half a beer)
I also made a trivial (but real) merge request to test my workflow:
@craftyjon Have you made that group DM yet? Where can I find it?
I do not understand this:
The PNG picture with the workflow flowchart is a bit troublesome, but most of the guide can be updated relatively easy. After I’ve managed to get to a merge request 2 days ago, I’m now ready to do some more serious work.
@gkeeth How are your efforts going? A simple way to coordinate and prevent doing double work is to agree who does which chapters. After most of the chapter are updated collaboration gets more complex, but git should be able to help there.
@Aris_Kimi You’ve also shown some interest to help, and may want to join the group DM that craftyjon promised. Apparently @ixhuti has also shown interest to work on the Blue/Green/Red flowchart.
At the moment I’m mostly waiting for some global coordination of who does what, as apparently there is now some interest from several people to work on this.
As a bystander who wishes he had more time to donate to this effort, I’m happy to see a group effort working on this. I look forward to seeing the end result.
A big thank you to all who are able and willing to put in this effort.
we can’t condone just copy and pasting content and then expect people to respect the GPL copyright on the source code in kind. So it quickly becomes not easy and requires obtaining permission per content you copy over.