On 11/4/2015 11:33 AM, Adam Wolf wrote: > I would like to add just a little to this: over the last few years, > many people on this list have spent a lot of time making the developer > community a friendlier place. This is not easy, and required hard > decisions by many people. > > Additionally, people have worked hard to make it easier to contribute to > KiCad. > > Please do not use the tone of emails from years ago on this list as an > indication of how things work today. We really, seriously, try to be > nice here!
It's not that I'm trying to be nice per say. I would say that I am trying to do the right things to move the project forward. Occasionally this will mean not being nice because someone is being disrespectful or belligerent and I will be force to step in and take action. This doesn't happen often and I will always attempt to be nice but there are always some who don't get it and have to be treated accordingly. > > Additionally, I'm seeing more and more emails that imply that the masses > of KiCad core developers are doing this or doing that. There are not > many KiCad developers. > > Every minute I spend on KiCad is only possible because my business sells > products we designed using KiCad. I looked around, and few people were > working on KiCad, and I had most of the required skills to provide > value. That was 5 years ago, oof. It goes by quick doesn't it? I'm pushing 9 years myself. > > To be a core developer of KiCad, regardless of the state of the > codebase, even if it was amazing and super testable, had no bugs, had > amazing documentation, you must have a good handle on the problem > domain, which is electronics design, probably have experience using > Altium or PADS or another piece of software that costs $10k+, and be > able to work on large codebase that must work on Windows/Linux/OS X. > > This probably means you're highly employable, but somehow have a > philosophy or delusions that make you give away your time. :) My money is on delusional! > > Based on my experience, then you'll make a cool new thing for KiCad that > everyone wants, and you'll find out that upstream software that KiCad > uses has two different bugs on two different platforms that require you > to learn their software and write a patch. Most of the developers here > have code or patches for CMake, maybe boost, probably wx... This is also a big factor in keeping talent. It becomes quickly obvious that developing a large cross platform application with many external library dependencies is not easy. Most developers never hang around long enough for the really nasty stuff like patching wxWidgets and Boost libraries to KiCad to build and run reliably. It's all pink ponies and unicorns when your adding that new ghee whiz feature only to have it dashed upon the rocks of cross-platform development reality. > > There are exceptions to this. Some businesses choose to pay their > employees to work on KiCad, but I don't think this is very common. > > This whole paradox is one of the main reasons why I push so hard to keep > the development list friendly. (The other is that being nicer, even at > small potential productivity hit, is something I believe is The Right > Thing To Do.). By keeping the list friendly, gradually improving code > quality, making it easier for new developers to successfully work with > the code base, and actively looking for things that non-core developers > can do, we help increase the speed of improvement and the longevity of > KiCad. > > (I do not speak for all developers, or even anyone else on this list.) I should have added this disclaimer to my comments as well. ;) > > (Wayne, I was just discussing with someone last night, that we might > want to have a monthly email that goes out on this list, which is a > devlist FAQ... What do you think?) It might be worthwhile adding the FAQ to the kicad mailing list so that new devs don't have search the mailing list for previous FAQs. I would think a monthly email might be a state of the union type email about what's going on in kicad development but that may be time spent elsewhere. I do think at some point, a developer's charter should be drafted so new devs have some idea about how the project is organized and functions and expectations in general. This would give me a convenient link to direct new dev to instead of rehashing the same discussion over and over again. It would give potential devs a chance to decide up front whether or not that working on the project is acceptable to them. > > On Nov 4, 2015 10:02 AM, "Wayne Stambaugh" <stambau...@gmail.com > <mailto:stambau...@gmail.com>> wrote: > > My responses below are pretty well known to most of the devs that have > been here a while. For the folks new to the mailing list, please read > on. I should probably put a lot of this in some type of formal > developer documentation ("A Word from the Project Leader"???) so that I > do not have to keep repeating myself. > > On 11/4/2015 8:32 AM, x...@sms.cz <mailto:x...@sms.cz> wrote: > > Hello, > > > > a good topic and good ideas, in my opinion. Though it should be > the core > > developers who should say that. > > > > A few weeks ago I was performing my own small research in what EDA > tools are > > available. I was looking for a > schema_drawing-simulator-pcb_creator all-in-one > > app. And found none (free). I was playing a lot especially with > QUCS and eSim > > (previously Oscad). Maybe I'm mistaken, but it seemed to me that the > > development in QUCS almost ceased, leaving the application in > unfinished state > > with simulation stability problems. And eSim (which is basically a > KiCad > > wrapper) adds very little functionality to KiCad, but creates a > completely new > > project manager with very restricted functionality and a lot of bugs. > > I spent a couple of days trying to get eSim to even run their examples > on Windows with no success. This did not instill me with much > confidence. The last time I looked, there was no OSX package. Any > changes to KiCad, must work on linux, osx, and windows. I don't think > that is an unreasonable expectation. > > > > > And here I'm coming to what you were writing about: All three > projects (QUCS, > > eSim and KiCad) seem to suffer with lack of people willing to > contribute. I > > agree with you that mutual cooperation could help all three projects, > > especially in the problem of lacking man-power. In particular, I > was wondering > > why eSim went its own way instead of by contributing to KiCad. My > suspicion is > > that one of the reasons may be the initial rejection by the core team > > developers to any unsolicited changes. I don't want to criticise > that, I'm > > just stating that this can be seen in the history of many patches > in the > > bug-tracker, where many suggestions were initially rejected, and > only after a > > long discussion they found their way to the KiCad build. > > To my knowledge, the eSim folks never presented anything other than here > is our simulator let's collaborate. The fact that they went and did > their own thing would suggest that they have their own agenda. I am all > for collaboration but that is easier said than done since it appears > that they have diverged significantly from kicad. To be honest, I have > not looked at their source and I wont have time in the near future due > to the upcoming stable release so I do not have a good idea of how much > effort it would require. > > > > > The question is - who will be the people driving the changes? This > is a free > > project, more than that - it uses GPL. And that's the reason why the > > development goes the way it does. On of the KiCad developers said in a > > discussion, that he is contributing to KiCad not make the word > better, but to > > make it suit his needs. And I completely understand that... :-( > > Such is the way of open source. The problem with the lack of kicad (or > eda in general) developers stems from the fact that you have to be more > than a competent C++ programmer to hack on kicad. You also have to > understand the problem domain which is designing schematics and laying > out printed circuit boards. The number of developers that have this > kind of experience is very very small. Many of them, like myself, > contribute because they actually use kicad to create printed circuit > boards and are not terribly thrilled with the idea of someone else > controlling their files which is what you get with propriety binary > (mostly) formats. Given our limited time to contribute, it's only > fitting that we work on things that interest us. Take that away and > you'll have even fewer contributions. > > > > > To be a little constructive: Your suggestions are good, but there > has to be > > someone who takes care of them. And any such changes need an > action plan/a > > roadmap. Like this one: > > http://www.ohwr.org/projects/cern-kicad/wiki/WorkPackages. (I have > no idea how > > is CERN KiCad related to this KiCad.) Because it's hard to > contribute to a > > project that has no idea of the way it wants to go. > > We actually do have an idea where we are headed and a road map (albeit > not updated as often as I should). The biggest issue is attracting > competent manpower that can work within the framework of the project. > We've had many developers submit their pet features with no prior > discussion with the development team. When they are rejected or are > asked to fix something they get offended and leave. This to is very > unique problem to open source. If you were getting paid by your > employer to do this and you refused to cooperate with the lead > development team of your employer, you would rightfully be out of a job. > We have no such authority over volunteers. We do have authority over > what we allow to be committed to kicad. That's the only leverage we > have to get developers to cooperate. > > > > > Martin. > > > > ----- Původní zpráva ----- > > Odesílatel: timofonic timofonic <timofo...@gmail.com > <mailto:timofo...@gmail.com>> > > Příjemce: "x...@sms.cz <mailto:x...@sms.cz>" <x...@sms.cz > <mailto:x...@sms.cz>> > > Datum: Wed, 4 Nov 2015 04:12:42 +0100 > > Předmět: About collaboration, simulation, documentation, organisation, > > usability and documentation (Was: Re: [Kicad-developers] Bug > #1511552 - Fixes > > to Incorrect export of Spice net-list from EESchema) > > > > > >> Hello > >> > >> I'm just a lurker and still not started to contribute, but I have > some > >> ideas: > >> > >> - Indian Institute of Technology Bombay: I see technological and > >> educational institutions as potential contributors at this stage of > >> development. Indian Institute of Technology Bombay developed the > Oscad > >> package and showed a very good attitude towards collaboration, I > think they > >> must go to FOSSDEM and talk very seriously about a long term > collaboration > >> plan. > > I think they need to improve the quality of their product and port it to > osx first. Then they need to draft a sane plan to merge the simulator > into kicad. Using another launcher on top of the kicad launcher doesn't > make sense to me. I would prefer that their simulation apps launch from > the current kicad launcher although I'm not opposed to replacing the > current kicad launcher with something better. The key word is "better". > Different != better. > > >> - Improving usability: I think UX should be taken under a very > serious > >> objective analysis by an independent group to make KiCad more > popular, > >> OpenUsability.org seems a good candidate. Old schoolers and some > developers > >> might resist to change, but KiCad's UX is one of the things that > still make > >> people uncomfortable to use it. > > I am not interest in making kicad popular. I am interest in making > kicad better. There is a significant difference between these two > objectives. For example: there are some folks who think clicking on an > object to highlight it then right clicking to get a context menu of > operation to perform on that object is better (more intuitive) than > simply hovering over the object and hitting the appropriate hot key > (simpler but with a learning curve). It may be more intuitive but it's > also a lot more steps to perform the exact same operation. Is this > better? We can do both but I will not bow down to the usability gods > who make it take longer to lay out a schematic and/or board (think > gnome2 to gnome3 changes). I actually use kicad at my real job to get > work done. For me, kicad is a productivity tool not a way to stroke my > ego. Anything that makes my life more difficult will be met with > resistance. I don't think this unreasonable. I'm always willing to > listen to suggestions on how your idea is going to make my life easier > as a board designer as long as your willing to listen to my suggestions > on usability. > > >> - QUCS: It seems a great project with innovation in their core > ideas. I > >> think there should be some collaboration. It seems there are > issues about > >> SPICE models being copyrighted so they have to use script > downloaders, this > >> would make a future KiCad library with all components available in > >> SPICE/Verilog-A a very hard challenge until solved. > >> - Organization: Are there clear roles in KiCad? Wayne is the project > >> manager and there are translators, that's all I know. Are there > main or > >> specific roles in the team? What about a fast voting process to take > >> decisions? Are there a formal meritocratic core team? > > KiCad is a meritocracy in that you earn status by contributing and a > willingness to work respectfully with the current development teams. > This means contributing code, documentation, libraries, scripts, etc. > It also means discussing those changes openly with the dev team and > respecting the input of others and the lead devs. As long as I am the > project leader or there is a huge shift in human enlightenment, kicad > will never be a pure democracy. Pure democracies are mob rules and > highly volatile. Do some history research on the ancient Athenians and > some of bad laws that came to pass due to pure democratic rule. > Hysteria does not make for good governance. Maybe in 1000 years (which > I think is highly optimistic) when humanity becomes a bit more > enlightened, pure democracies may be a viable way to govern. Since I > wont be alive then, it be a problem someone else will have to solve. :) > > >> - Wiki: What about using a wiki for documentation? It provides an > easier to > >> use environment, it can be customized for i18n and even parsing > KiCad > >> files to show them as SVG if someone writes a plugin for it. The > >> documentation could be exported and shipped in each release, too. > > I would suggest that you discuss this with our documentation developers > on github. I doubt they would be too keen on moving to a wiki based > platform. We just recently converted from odt files to asciidoc which > is automatically regenerated to translated html, epub, and pdf formats > when a pull request is made on github and linked to the kicad website. > I really like what documentation and website dev teams have done and > they have my full support and thanks for their efforts. I'm not > convinced a wiki is a good idea. You would have to convince both me and > more importantly the documentation team that that using a wiki makes > sense. > > Cheers, > > Wayne > > >> > >> > >> > >> Relevant links: > >> https://forum.kicad.info/t/simulating-kicad-schematics-in-spice/ > >> http://mithatkonar.com/wiki/doku.php/kicad/kicad_spice_quick_guide > >> http://esim.fossee.in > >> https://github.com/Oscad > >> http://www.iitb.ac.in > >> > >> Kind regards. > >> > > > > ______________________________________________________________________ > > Vystup z řady a zřiď si taky originální email! @bigboss.cz > <http://bigboss.cz>, @dablik.cz <http://dablik.cz>, @potvurka.cz > <http://potvurka.cz>, @tajny.cz... zdarma na http://email.sms.cz > > COMDOM Antispam - www.comdomsoft.com <http://www.comdomsoft.com> > > > > > > > > > > _______________________________________________ > > Mailing list: https://launchpad.net/~kicad-developers > > Post to : kicad-developers@lists.launchpad.net > <mailto:kicad-developers@lists.launchpad.net> > > Unsubscribe : https://launchpad.net/~kicad-developers > > More help : https://help.launchpad.net/ListHelp > > > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > <mailto:kicad-developers@lists.launchpad.net> > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
