Q:

How is it best to go about asking a potentially massive series of questions?

I'm working on a few projects I've fiddled with for years, and I'm starting to get to the level where I can actually build something quite nice I think for at least a few of them.  Obviously people here appreciate as much background information as possible when answering questions, but I'd like to prioritize things to the degree I'm able, and dropping a full description of the project in each question could become quite tedious for the reader.  I also am very conscious of my learning process, and I tend to learn things well, but sometimes go through multiple phases of theory and experimentation before I really start to comprehend the technical documents.  I think it would be useful to include a link to an accumulation of the relevant data.  Crosslinking all of the questions as they come up I think would be messy.  I've been thinking about using google docs and/or google sheets.  I think I'm able to set things a public viewable but not changeable.

Does anyone have recommendations for what service to use?  Perhaps something less mutable than Google docs and Google sheets?

What about double, triple and or quadruple stacking questions?  Just like this?  To what degree is it acceptable, especially a set of questions that are related to each other and within the same project?  This time I'm going to just go ahead with it.

Asking for personal preferences for methodologies, or more particularly parts.  I gather this is frowned upon, and I understand nobody wants the site to turn into an advertisement board, but one serious problem for an entry level maker like myself is that technical documents and articles and announcements about parts are often from when the part is released.  Everything is "the best", and parts usually have to be really old, 15, 20 years or more before documents are updated.  Especially with things like high power LEDs, a bit of experienced insight on these types of parts in invaluable, telling you things like which LED has the best efficiency as a flood, with a certain minimum CRI, or as a dedomed thrower.  I have a good idea of the current "best in slot" for the sizes and voltages I'm interested in working with right now.  Brands other than the "best in slot" are regularly used in commercial products, and many of them are orders of magnitude cheaper.

Price would be part of the reason, but I suspect this works partly due to the fact that luminous efficacy varies with drive voltage.  One thing I'm interested in experimenting with is the degree to which I can underpower something like a 50W COB LED to get performance similar to, say a 25W "best in slot" LED running at rated wattage.  This is a case where I'd be prone to ask an experience based side question.  I can only imagine requesting mention of any low end COBs that people had played with as a side question really, as the "Question" itself should be specific enough that it can be specifically answered.
I'll verify things when important or necessary, or even if I'm just curious, but an offhand comment about driven LEDs while reading forum posts about troubleshooting drivers can save me reading hundreds of technical documents.  Can you give me an idea what about these questions irritates people most so I can best gauge when it's OK to ask?  Is it OK to mention, so long as the "Question" in question is adequately specific?

Questions about discipline:

Another example question:  This will probably be the first I ask, just assembling documents and such.  Second I ask including this one I suppose.  It will go something like this:

Title: How best to reduce this set of discrete logic units?
I've been working on a project to accomplish X and I'm trying to go about >it in such and such a way.  I've come up with the following set of logic >gates:
[picture of said gates with explanation of what each section is doing and >how]
Each set of gates forms one section of this modular circuit (link to logic >simulator on another site to demonstrate function of circuit.
I'm interested in doing this project with discrete components for these >reasons, as I'm not ready to move on to FPGAs or microcontrollers.
I'm aware of the following disciplines (boolean algebra and state engines) that are used for working with this sort of problem, and I normally work on it this way: (neither).  Given that in this case, I want to reduce discrete component count while still using single 5/6 pin chips.  I see that I've kind of built a triple latch, but I don't know yet how to deal with feedback loops in boolean logic.  My brother is lending me his old textbook on state engines, but the more I read on them, the more it appears because this is an N-channel design(modular) the number of potential states will increase in a more than linear way as states are added.  Are there any obvious solutions or reductions that I'm not seeing due to my inexperience?  which of these, or other discipline is best for this sort of problem?

Obviously when I ask it I will include the necessary complications, but is this viewed as an acceptable question to ask?  I'm hoping I'll be able to ask almost any question within the bounds of what I can tell I don't know and at least find out what to learn next.

(b) Extension of a question:  In the case above, having discovered which disciplines might apply and why, the implicit next question is having selected a discipline, started to process related material, I'll immediately identify some of the things that don't make sense, and I'll want to ask what foundations I'm missing for understanding them.  Is it OK to pursue addenda for the sake of not producing full extra posts over smaller or not immediately apparent matters?  Feel free to pretend 4b didn't exist until you'd already answered the rest of the question.

Thanks for your input.

A:

The purpose of this site is not to give you the equivalent of a college education in electrical engineering. Do NOT dump a large series of lengthy questions on us.
As a beginner, you will find that many of your questions have already been answered here (or elsewhere). Please take the time to do the research, both on this site and on the Internet in general, before asking a new question.
Ask one question at a time, and do not ask another until you understand the answers. Provide enough context so that we understand what you're doing, but don't go overboard. It may take a few tries before you get this right.
Also, we discourage broad, open-ended design review questions, because the answer(s) tend to become long strings of unrelated edits and/or comments. While this might help you with your immediate problems, it is of no value to the site overall. We DO allow design review questions in which you explain your choices and then focus on a few points about which you still have doubts. To get a better feel of what is or is not acceptable, search for "design review" on the meta site.

