Start by pouring your ideas into one big bucket.
Then as you find patterns, you can move items into smaller buckets. Smaller buckets, but not small buckets- you want a good number of ideas per bucket, if that bucket's going to be useful. You should not have a bucket with only one idea in it.
(A lengthier explanation of these ideas appears on BigBucketsFirstExplanation.)
One example of this concept is organizing the pages on a wiki.
When a wiki starts out, it is very small. Maybe you have 3-7 pages on the wiki. How should they be organized? Put them in one big bucket. On the front page of your wiki, list all 3-7 pages on the wiki. Maybe you want to give a one line description of what the page is about.
But over time, your wiki grows. You write lots of pages, and you notice patterns. It becomes useful to associate collections of pages.
Eventually you divide the page into several pages. But it's a mistake to make lots of pages with only a few links on each, early on.
The idea of the manifest is to show what's present.
The idea of the organization is to show related ideas together. That way, you can understand what's present, and find things better. All sorts of benefits come from a good organization. But key to it is showing ideas in their context. Part of that means obscuring some things, and emphasising other things.
When you have a small bucket, though, you obscure too much. And you emphasise too little. You have to be a good judge for yourself, to figure out what's too much, or too little. We can't do that work for you.
Why do we say "Big Buckets First?"
Because when you have only a few data points, only a few pages, you want to see all of them.
Little buckets aren't useful. If you have a bucket of only 3 pages, what good is that? Show the user 20 things. Sure, you can segregate those 3 pages. But do it on the same page. Give the viewer a broad view. Then they can understand the context better, even though they may not use it all.
And, we want to make sure that we're making buckets for pragmatic reasons. We want buckets that make sense by pragmatic use- not by what we imagine that we may need. (Because, frequently, our second guessing is wrong.)
LionKimbro (feel free to rewrite the page)
Hope y'all like it. 
I like it a lot Lion. It stimulates a question about the process of dividing a big bucket up. In your outline a "pragmatic" approach sounds a bit too much like "common practice", for my comfort. In common practice a "big bucket" can only be worth of attention if it can be described by a "business plan" ... What about saying that a "big bucket" is a dream, such as defining a Web User Destination Approach [1] .. What if the process of dividing up that kind of bucket cannot be handled by its dreamer alone ?
I like it too. Thanks Lion. Useful contribution to initiate some new french CommunityWiki... Let's say I will drop a first french draft translation on GrandsSeauxEnPremier 
Thank you, both of you. 
Luigi, I don't totally understand what you mean.
It seems like you are suggesting that dividing up big buckets is something that one person couldn't do alone.
But we do it alone all the time. (As well as in groups.) So, I don't think I understand what you mean..?
-- LionKimbro
Oh, okay..! That's cool. I like using star terminology. "Buckets" is rather CS-ish. (Computer Science-ish.)
How about "IdentifyBigConstellationsFirst?" Or, "BigConstellationsFirst?" But, it's a bit long.
"BigClustersFirst?"
Luigi, in case you're reading: Still wondering what you originally meant. 
Whatever a big bucket might be Lion, I wish it could be something greater than the sum of its parts.
Today I overheard this phrase from a radio in my background (I could not catch who was reported saying it): When we dream alone a dream is just a dream; When we dream together a dream is the beginning of a new reality.
I believe I have just written the same answer to your question in two different ways.
From my old guy viewpoint a pragmatic approach to dividing whatever big bucket always starts from a shared, or sharable, perception of some already existing and well understood reality, that can be divided into a clearly defined number of parts.
If I can still be lucky enough to contribute to dividing anything into smaller parts I would want it could happen from the bottom up, without a clear understanding of the whole I'm contributing to a part of, but with the type of strong inner motivation, to go about it, that I would be unable to express in rational terms, same as what makes me listen to music I like or look at a sight I find fascinating, without a need to explain what and why it is that way.
Now, this explanation of I what I originally meant needs a not-just-linguistic translation ... into practical terms.
I do need an interpreter ... I'm afraid 
Okay- re-reading, from the perspective of someone who doesn't recognize the word "bucket" as it's being used, the source of confusion is clear. At no point did I explain what I meant by "bucket."
I've written BigBucketsFirstExplanation. It's a "plain talk" explanation of the ideas here, and I think it should be a lot clearer..!
I'm thinking of making this page a little more abstract, if ChristopheDucamp doesn't mind..! (Because, it will spoil the translation he did.) Or maybe I'll make a page: "BigBucketsFirstAbstract?," trying to pin down the specifics of why this works. I fear making a full theory of organizing, though.
Let me know if BigBucketsFirstExplanation is clearer, or if this all still needs some work.
-- LionKimbro
Still don't know how to translate pattern 
I'm trying to gather more insight into developing ideas on a wiki. This concept, BigBucketsFirst seems to be suggesting, as a way of starting on a fresh wiki, (where you may have very little on it yet) you might include only one or a few pages. Later, you can divide these up. It makes it easier to 'see' the big picture by keeping it in one place.
When I think of this, in terms of an established wiki- I wonder if/how it can be applied to a theory of developing ideas in a group. Ie, you compose pages that have many ideas on them... and later, when you understand them better- you break them down.
But I know this goes against my recent tutelage from Lion- namely that you can't come with One Big Idea- you need to consider and break it down into components. But then, how can I do this alone? I need some way of showing One Big Idea, and letting others help break it down. Otherwise I might as well not develop ideas on the network.
What I'm trying to get at here is: I'm not very good at wiki, and I want to get better. Part of this will take practice. But since I am trying to work with others to wiki, I want to be able to articulate the process.
The best way, I think, for me to articulate the process is to understand how more experienced people wiki.
So- here I see the idea of big buckets... what is the converse of this for an established wiki? Something about components-before-conglomerates?