Support forums : Branches

Blueprint guidelines

Discussion about existing branches and the directions they need to go in, or, for branches that are going to happen. "Quickies" is wide open. "Branches" is more focused.

Moderator: Dracones

Blueprint guidelines

Postby Yabs » Sun Dec 13, 2009 3:36 pm

Ok, whilst we're still deciding where and how we want to deal with blueprints, we need to come up with a workflow, that mostly works, for now.

So, how's this ?

  • Decide there's summat about the core that you don't like, or would like improved, or added, or whatever the hell your reason is
  • Create a post in _this_ forum with some placeholder text, "reserved for blueprint" is unimaginative but descriptive
  • Reply to your post with *your* reason for the blueprint and any pro/cons
  • We then debate endlessly and wander off topic a few times
  • Eventually some form of consensus is reached and the placeholder should be replaced with a real blueprint
  • An LP blueprint should then be raised which summarises the "real" blueprint
  • Link this blueprint to LP blueprint and vice versa
  • Move (this) blueprint to the appropriate milestone sub-forum

¥
I may have opened the door but you entered of your own free will

Image Techno Babble II
Image Tacky Pad 3
Yabs
Dracone
User avatar
 
Posts: 896
Joined: Sat Nov 21, 2009 9:59 am

Re: Blueprint guidelines

Postby EdB » Sun Dec 13, 2009 11:55 pm

With a "initial release", "second release", or, "way out there" as sort of a prioritization system. Not everything will happen for the first release is the thing but we obviously can begin building a framework that'll one day contain the bits we know of.
EdB
Dracone
User avatar
 
Posts: 2072
Joined: Sun Nov 22, 2009 7:20 am
Location: Maricopa Arizona

Re: Blueprint guidelines

Postby Yabs » Mon Dec 14, 2009 10:04 pm

atm I'm using "here" as "way out there", milestone 0 for "ground zero release" and milestone 1.0.0 as first step we take on the moon .... although my speech may not be as memorable :(

but, yeah @ framework for the future ;)

¥
I may have opened the door but you entered of your own free will

Image Techno Babble II
Image Tacky Pad 3
Yabs
Dracone
User avatar
 
Posts: 896
Joined: Sat Nov 21, 2009 9:59 am

Re: Blueprint guidelines

Postby EdB » Wed Mar 31, 2010 4:22 am

Wanna try to get this blueprint thing figured out since 2 of 3 votes in the "dead weight" poll say both and the third says open, which means all 3 say open, which means we should maybe embrace this blueprint thingie.

IF I get it right, a blueprint is kind of a higher level type of thing, probably with a few to many branches that get worked toward that goal. Kinda like in WWII the "pacific theater" was a blueprint - a big picture idea of kicking some Japanese ass. To do that took many specific battles, which would have been the branches.

So if that is right then there should have been a blueprint to discuss something like "cleaning up the plugins folder". In there we would have figured out and branched (1) merge widgets and plugins into the same folder, (2) make widgets be a real grown-up class thing, (3) make sure plugins have nice readmes, (4) get localization for each plugin instead of in the core. That 4th would have also touched on a possible blueprint regarding localizations.

So then the "deal with localization" pluebrint might look at things like trying to resolve cases where spaces or punctuation are not really appropriate in the translated string, localizing plugins, discussing the NT_ function, discussing localizing templates. Each of those might have spun off a branch, or been dropped.

In the end, and correct me if I'm wrong, but a blueprint might actually spin off some branches while all the details are still being worked out. Seem right? If so, or even if close enough, I'll start working on at least a plugins pluebrint because there is still quite a few details to work out.

Oh and another one for the whole autodocs thing, which is a go-nowhere blueprint until someone gets motivated to start writing docs for it, and maybe tweaking docblocks in template functions again. Which would cause some branches to align with multiple blueprints because tweaking translatable bits will affect the "canned code snippet library" that autodocs accidentally became.
EdB
Dracone
User avatar
 
Posts: 2072
Joined: Sun Nov 22, 2009 7:20 am
Location: Maricopa Arizona

Re: Blueprint guidelines

Postby Kimberly » Sat Jul 31, 2010 8:21 am

Uh, I did not read the guidelines before posting. bag girl kimberly, bad girl.
Kimberly
Dracone
User avatar
 
Posts: 842
Joined: Mon Jul 19, 2010 4:44 pm

Re: Blueprint guidelines

Postby Yabs » Sat Jul 31, 2010 8:25 am

No worries we only shoot first time offenders ;)

¥
I may have opened the door but you entered of your own free will

Image Techno Babble II
Image Tacky Pad 3
Yabs
Dracone
User avatar
 
Posts: 896
Joined: Sat Nov 21, 2009 9:59 am

Re: Blueprint guidelines

Postby EdB » Sat Jul 31, 2010 8:50 am

Kimberly wrote:Uh, I did not read the guidelines before posting. bag girl kimberly, bad girl.

Does someone need a spanking perhaps (he says with a gleam in his eye and a wee bit 'o drool trickling from the corner of his otherwise lecherous mouth)
EdB
Dracone
User avatar
 
Posts: 2072
Joined: Sun Nov 22, 2009 7:20 am
Location: Maricopa Arizona


Return to Branches

Who is online

Users browsing this forum: No registered users and 1 guest

cron