I see it this way, they are sub-projects or projects within Fedora, but as in a body you can't just strip the arm off. If they part of such body, I believe there are points that should be contemplated, like this for example:

 * They increase notoriety of the main project.
 * They offer a wider choice to users.
 * In some cases, they are focused on segmented targets.
 * They aim for different audiences

But they are still a part of Fedora. It's true they can have their own SWOT and their own strategical lines defined by them. That's why I really don't how to approach it.

 

Well it's on the webpage. It's going at a slower pace due to some issues I'm finding. In my first approach, I went too much superficial and I've decided that such approach though would be 'correct' would not expose the whole process as I wished, so many people could still not understand what was behind it. So I changed the design of it, and forced to implement the 5M. Which eventually is wrong and is right, as there are other alternatives, though this one provides probably the best mechanism to expose the methodology for everyone to understand.

Another thing I've done was in strategical points to start on the opposite way, by attacking the point as I wanted to bash it down. This had a purpose, to prepare myself to defend such such point already thinking on possible attacks to it. This delays the whole process, but the concepts are there in a way that I can defend them on a 'workable' conclusion.

If we take a normal SWOT approach like I do on academical papers and  ignore the exposition of the methodoly and just dump the technical terminology, that would make it faster to do, this way takes more time, but I assume it will be easier for everyone to understand.

I really don't know how much is done, what I can say from what I am doing is that the real thing is actually focused on internal environment which are the points Fedora can actually work around. The External Environment, maybe for some Macro Environment isn't going to have much things, except the typical legislation, blockades, special cases and eventually something risen in other thread about M$ and Apple.

 

Theoretically, it should be done and analysed, from there, there should be a complementary part which is not present on that document, the real Analysis and a set of guidelines to follow in order to correct the flaws on the strategical side. Based on this, in a time frame you can judge how things went and if the problem was solved.

At some point, I aggree with what you say, but we should actually define it for a cycle for example. If it happened on the beginning of the cycle, by the end of it we could take conclusions and rework it. Keeping it always on change, I'm not sure on how we can later evaluate things.

Heirik, honestly, I don't care about the looks or on much people want to update rework, etc... it's more important for me for people to understand the concept so later editions can be worked faster and by everyone.


 

 I believe I answered this already previously, but there should be a complementary part on it with the analysis itself where you relate everything, identify your flaws and proprose action on the things you want to change. Applying this to a release cycle, on the end you can judge it. This part should also contemplate the goals and how you evaluate your success. I haven't done this on the current document. While I want to make clear the methodology and can point the way with basic stuff so that people can work it after and have it as an example, such analysis, I believe it should be made by whatever or whomever wants to do it.