Steven Edwards wrote:
Hi,
--- Filip Navara <xnavara(a)volny.cz> wrote:
I doubt someone would vote for me, but if it would
be collective
decision I'll not object. (Personally I have two candidates for the
position that I would propably choose from in the voting...)
Well I am divided on who I would vote for as the people I named would all be great in the
role but
I would like to hear something alone the lines of
"If I was KC I would try to implement the following development method, rules,
reactos coffee
maker, etc...."
Thanks
Steven
Well since a bunch of people have recommened me to apply, and since I
don't think it's a bad idea, I'll start my own little rant.
I feel I should be KC for 4 main factors:
- Technical knowledge
- Vision
- Diplomatic abilities and attitude/contacts
- Free Time
I'll elaborate on all of these points below:
1. Technical Knowledge
---------------------------------
In my opinion, I have a vast amount of knowledge on NT's Kernel Design
and Architecture. Although I admit that I have some weak points in the
Cache and Memory Managers, I know the other subsystems like the palm of
my hand. My knowledge has always went into applying it into code and
fixing broken parts of ReactOS, as well as implementing new APIs (I have
implemented around 100 new APIs). Secondly, this knowledge has also went
to help other developers who were in need. I have always been a helping
hand in the channel, and developers often come to me to seek answers to
technical questions, architectural design or just some weird
undocumented API or structure. My code is of relatively high quality,
even though it can sometimes have bugs (beware of bug-less code). I
always properly test code in a variety of scenarios, and for really big
patches, I also have other people test them for me (Waxdragon can
attest, for example). I highly value code review and testing procedures.
In sum, I know a lot, I produce a lot, I help a lot and I'm structured
with my knowledge and its product.
2. Vision
----------------------------------
Since my beginnings at this project, I have always had a clear
consistent vision:
1) Developers should be allowed to work on whatever they want. I do
not believe in forcing people, but I'm not against having "Focus Weeks"
in which the developers would be invited to focus on something, if they
wish to. But I am against telling people what to do, and this has been a
great freedom that ROS coders enjoy.
2) We must strive for 100% in order to achieve 90%. I have always
believed that we must pay attention even to undocumented APIs and
closely mimic Windows behaviour to the external callers. For example, is
MSDN lists a parameter as 'reserved', but we later find out by a test
case that it's being used, then I don't think it's OK to say "well,
everyone listens to MSDN and nobody will use the reserved parameter".
There is always a chance for some developer finding out what the
Reserved parameter does, and using it. If it's on MSDN, the change is
actually pretty large. Sometimes MSDN themselves document/undocument
various parameters and APIs. *IF* the developement effort is minimal and
someone wants to do it, then I strongly believe that reserved parameter
should be handled. It shouldn't be a priority, but it shouldn't be
ignored. Even if we only make 5 extra apps work, the sum of "All these
little things" will make 5000 apps work. And that's a key difference
between 60% and 90%. Sure, most people use only the 60%. But some very
big clients could use the other 30%. Do we want to ignore them? Not in
my view.
3) ReactOS is not a game project. It will become a serious tool,
similar or superior in popularity to Linux. Many people mock us, or
think of us a past time to code. Maybe some of the developers also feel
like that (I don't think so). However, I am truly *dedicated* to
ReactOS. I believe in its future, and I want to be a part of it. I am
not only coding to spend time. I am coding to make ReactOS a powerful OS
that will be used by the masses. I am coding with the same passion and
desire to free the world from proprietary OSes just like Linus strived
to free the world from UNIX. I am here in the long run, and I see a
future for ReactOS in 3 years. I see 1.0.
4) Structured views. I have always viewed everything in a structured
fashion. I know the goals (in the Kernel) for each major milestone, and
they are achievable and plannable. I don't believe in totally random
coding that will get us somewhere. I feel that I have a deep sense of
organization that is needed for a KC.
5) PR and Users are our target, not power-users. The problem of many
alternative OSes are that they try to be "leet" or "high-tech" for
power
users. Many boast "built-in compiler!" or "emacs-based web browser!"
(silly examples). These are cool toys for the Linux geeks, but not for
Windows users. I know it sounds like what we are fighting against, but
our OS must also boast things like "Easy to use!", "Friendly wizard for
Desktop Organization!". I'm not saying that we need to create Clipit,
but we defintely need to emulate and also ADD our own wizards, helpful
tools, and yes, even themes. Because in the end, our users make us what
we are, and it's them that will decide our success. And to reach these
users and get our point across, we need good PR and good Marketing. This
is why Firefox has been so popular, and we will eventually need such a
campagin as well.
3. Diplomacy/contacts
---------------------------------------
I have an ability to solve conflicts, and although I've been in the
center of two large flame-fests, I think the end situation came up
pretty good. In the branch affair, I admitted my mistake and the created
mini patches, with some help, in order to get the code in. Sure I was a
bit offended at first, but in the end the situation was solved nicely.
Whenever there is a conflict, I've always tried to solve it in a
diplomatic way, and have never forced my point of view on someone. I've
never reverted someone's code, as some people have done in the past, but
have always asked the person to do it, and gave my reasons why. And
sometimes people refused and I was wrong, or other times I was right and
the person understood. In each case there was trust and understanding.
I also have pretty close ties with most of the developers and know most
of them personally, and met with some of them as well. I would say I'm
pretty 'connected' in the ROS crowd and talk with almost all the active
devs on a weekly basis (a lot of them on a daily baisis). I also have
some important contacts outside the ROS world, which can be very
valuable for PR and also for Development in general.
Finally, I have very good English/French/Spanish/Romanian writing and
reading skills, love producing documentation, doing presentations etc.
4. Free Time
------------------------------------
My final point is that I will have a lot of free time to take care of
this, at least for the next year. Many developers have a job, a family,
etc, but I have none of that. I'm happily in front of the computer,
dedicating 90% of my time to ReactOS. When am I not on IRC? I'm always
opened to emails, I read the ML, and I'm pepetually on IRC. I'm an
available and open person.
Finally, I'll end with my goals as a KC:
- Expand the Wiki with some basic Kernel Keywords (I've already
started on this)
- Be present as a mentor, problem solver and decision making individual
- Insist on good quality code, good coding habits, testing
procedures and code reviews.
- Come up with a plan to solve quarrels between developers on a
certain issue. Preferable through a vote, or moderated by someone that
has been known/chosen as an expert in that field (note I said moderated
by, not decided)
- Set up clear plans all the way to 0.5.0
- Continue to work and improve the kernel.
- Collaborate with the Project Coordinator on wider project-related
advancements.
- Give interviews, promote, "sell/pitch" ReactOS to users, the media
and companies from my point of view (ie: give presentations at
conferences about our kernel, give seminars at univerisites, teach
people about the benefits of an NT kernel and our implementation of it etc).
- "Do no evil" (c) Google
Best regards,
Alex Ionescu