← Back to team overview

kicad-developers team mailing list archive

Re: launchpad blueprints

 

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