2010/6/19 wonderer <wonderer4711@xxxxxx>
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.
hy nelson,
> 2) Approach in a more objective and localized scope and treat SPINSI would think it would be more the second choice, because spins are more
> individualy.
projects from smaller groups within. The mainfocus is and should be
allways the fedoraproject itself.
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.
But first I would like to ask more about the SWOT going on at the whole
project. How far we are there?
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.
SWOT is an ongoing proces which can and
will be edited, formed and updated every time we use it. So I think it
will be best to begin with some points of the SWOT so far we have it and
look how this will go on.
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.
At this point I also have the question on how
to measure the results so that we can use them in the next Release cycles...
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.
mit freundlichen Grüßen / best regards
Henrik Heigl - wonderer@xxxxxxxxxxxxxxxxx
PGP/GnuPG: 8237 D432 0616 D567 DBC6 3FE3 0D52 B374 F468 A5F0
--
marketing mailing list
marketing@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/marketing
--
nelson marques
nmo.marques@xxxxxxxxx
-- marketing mailing list marketing@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/marketing
