← Back to team overview

kicad-developers team mailing list archive

Re: launchpad blueprints

 

I have setup something, to use along with the blueprints (almost wrote
footprints... erhmmm..)

http://pads.kicad-pcb.org

Nice to write little specifications that can be linked. Real time
collaborative, and has a chat. Runs on nodejs.

Data is stored in a mysql that's backed up weekly with the whole website.



Miguel Angel Ajo Pelayo
http://www.nbee.es
+34 636 52 25 69
skype: ajoajoajo


2013/9/15 Dick Hollenbeck <dick@xxxxxxxxxxx>

>
> On Sep 15, 2013 8:43 AM, "Miguel Angel" <miguelangel@xxxxxx> wrote:
> >
> >
> >
> > 2013/9/15 Dick Hollenbeck <dick@xxxxxxxxxxx>
> >>
> >>
> >> On Sep 14, 2013 3:46 PM, "Miguel Angel" <miguelangel@xxxxxx> wrote:
> >> >
> >> > Checking our blueprints, they look more like a wishlist.
> >> >
> >> > What do you think of dumping the list, (wget -r  > .zip > dev mail
> list) so we don't forget about the good ideas that we can transpose later
> into the wishlist (under the bug report system).....
> >> >
> >> > then closing them all -but for the really planned features, of
> course-, and then start from 0  ?
> >> >
> >> > 2013/9/14 Miguel Angel <miguelangel@xxxxxx>
> >> >>
> >> >> Yes, this is +/- the idea, in this project they set milestones, and
> use the blueprints to keep the focus, or track of the decissions:
> >> >>
> >> >> https://wiki.openstack.org/wiki/Blueprints
> >>
> >> When I last looked, launchpad's blueprints did not support
> discussions.  Do they now?  Without that  I found them pretty worthless.
> >>
> > Yes, something to allow comments in them would make them much more
> useful, I missed that too...
> >
> >
> > When I've seen people using them, they provide the link to blueprint
> during any discussion regarding the feature, and people keep track of the
> important details in the blueprint itself, so you don't have to re-read a
> long discussion on a feature planning.
> >
> >>
> >>
> >> >>
> >> >>
> >> >> ""  A bug is a description of a problem, and a blueprint is a
> description of a solution. ""
> >> >>
> >> >> "" Keeping their status current is critical to the success of the
> release and the project as a whole. It avoids unnecessary reporting, pings
> and discussions, and keeps everyone on the same page. ""
> >>
> >> I don't think so.  The project has never suffered from lack of ideas or
> direction, only from lack of lines of code.  Those come from qualified
> man-hours.
> >
> >
> > I agree, but I'm wondering if we can get more of our hours&mans, or even
> get others joining on the workforce if we provide little implementation
> plans (1-2 pages) with every feature idea we register.
> >
> > Starting to work on a software like KiCAD can be hard for the newbie,
> but sticking to a plan, can ease it..
> >
> > I'd like to give it a try on my next propositions, once the python
> documentation is ready I'd like to propose on:
> >
> >   0) Some QA proposition to keep the scripting side tested (and plenty
> of examples).
> >   1) Scripting refactor: to make the implementation cleaner, and easier
> to grow.
> >   2) Pluggable FILE IO scripting modules.
> >   3) Pluggable scripting modules to add context menu actions on pcbnew.
> >   4) 2nd round to make footprint wizards better.
> >
> >
> >>
> >> More than enough wishlist items, blueprints and suggestions.  Keeping
> track of them seems to have no effect on lines of code per month.
> >>
> >
> > Dick, do you mind if I give it a try, cuddle them for a while, and see
> if it is for good or a worthless effort?,
>
> No I don't mind.  It cannot be harmful, even if it proves unhelpful.
>
>
> >
>

Follow ups

References