← Back to team overview

kicad-developers team mailing list archive

Re: launchpad blueprints


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
  1) Scripting refactor: to make the implementation cleaner, and easier to
  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?,

Follow ups