(Note: This message was originally sent to xpl2. He suggested that I post it here, so that is what I am doing. Alot of what is in here is personal experiance.
Comments, suggestions or whatever is EXTREMELY welcome, and encouraged.)
Well, there has been two days without any posts on the boards, so I am going
to write this dorectly to you. First, as I posted on the board about an IRC
server. I can get one set up for all of us to meet together on and discuss
things. I think it be the best way to go about it, personally, as everyone
has (access) to an IRC cliet, the bandwidth used is quite minimal, the
machine power that is needed is quite minimal and I think it is quite easy.
Secondly, I have a few ideas I would like to share with you at the moment,
as at my prior company, I was the project leader for a new extension to our
corporate web site. I know that you are the guy in charge, when it comes to
this particular project, but I just wish to relay some of the things I have
seen/known to work.
1. Define a Project Abstract. All that this is a document that defines some
key points/goals/etc. of the project. Primarily intended audiance, goals and
a timeline. The timeline should logical divisions, ending in a specific
goal, of the expected progress of the project.(The bigger the project, the
less value that is place on the timeline as an absolute, and more a rough
guide.)
2. After that is done take the first logical division and determine what is
needed to meet that particular goal. This will usually include sub projects
that have their own individual goals.
3. Determine the skill set(s), stengths/weaknesses of each group
contributor, and most importantly, find out what subproject(subgoal) of the
first logical division most interests them. (Proven fact that people do a
better job when it is something that they like.) Group the people together
and designate one as a project manager.
4. Set a date that each subproject MUST be completed by. (This I have found
is a good technique, making a HARD, SOLID date. I am not saying that the
date is the date it must be completed or else, but the *impression* that it
is the date it must be completed. I once told some of my reports under me to
get me something in a couple of weeks, well it turned out to be a couple of
months. When I gave them a date (and a reasonable date at that, I got it in
on or (in MOST cases) before that date. If more time was needed, I granted
it, but still set another date.) This needs to be discussed with the project
manager (and possibly their whole group) also, to make sure it is
reasonable.
5. Have each project manager assign a timeline and such for their indivdual
project. (Basically they follow steps 2 - 4 for their subproject.
6. Set up a mailing list for each subproject, and the logical division. (I
could look into it, if this is something you wish to do)
7. Encourage the project manager to have regular meetings (IRC?) with their
group. (Every week or two, or what they feel is appropriate.) Have regular
meetings with the project managers. (Every two weeks, month, or whatever is
appropriate.)
8. For the most part, stay out of the subprojects, and leave them alone,
except for the ones you (the whole project's manager(s) admin(s)) are
directly involved in, request for assistance or are faltering.
Thirdly, I think it may be a good idea to do an Ask Slashdot. Something of
this nature, maybe: A new distro is being created... What do the readers of
/. feel the target audiance should be, what is lacking in other distros,
what is good in other distros, what can/needs to be improved. Something
like that, I think would generate huge amounts of ideas and get more people
to join Maximum Linux.
Fourthly, it may prove benificial to incorporate Maximum Linux into a
non-profit, for serveral very important resons: (Don't quote me on all of
these, I am not an MBA or a lawyer.)
1. Corporate Shield -- Something goes wrong, you nor the developers can be
held personally liable.
2. Volunteers -- (Don't quote me, I am not positive) For-profit companies
cannot, except in special circumstances, have volunteers.
3. Donations -- (again, don't quote me, I am not positive) For-profit
companies cannot, except in special circumstances, reeceive donations.
Being a non profit, you could for instance, request VA Linux donate a system
(or whatever), they would be able to get a tax break from it, making them
more likely to do so.
AFAIK, a non-profit must take all clear proffit (after bills, salaries,
debts, etc have been paid) and put it back into the company.
These are just my thougts, that I have learned over the years, and wish to
pass on to you. You may already know this and I wearing out my keyboard for
nothing, or you may not, and it has give you some ideas. At any rate I am
quite ready to help with the project in what ever way you see fit, be it a
secondary admin, a project leader, a developer, whatever, please let me
know.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I like the idea of an IRC server. We could also consider getting a registered channel on OpenProjects. We *will* need a place were we can chat in realtime, else this project won't move efficiently.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
IRC is definitely a good idea...something we should be doing as soon as possible. I think the /. idea is an excellent idea in terms of exposure and eliciting participation from the community.
--good to see someone thinking ahead
--dave
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
IRC is definatly a bad idea.
It assumes everyone can be on at the same time.
The internet is a global medium. I for one am not getting up
in the middle of the night to be entertained by horibla spelling of off the cuff remarks and banal chatter.
Writing email , or even forum postings, forces one to THINK
before posting.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I really have to disagree. Not everyone has to use it, but for those who wish to use it, it is there. Like all good things, it is an option for people to use if they want/feel the need to.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
you would have me on board definately if this was one of the major aims of this distribution.
peace
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2001-05-12
>Define a Project Abstract. All that this is a >document that defines some
>key points/goals/etc. of the project. Primarily >intended audiance, goals and
>a timeline. The timeline should logical >divisions, ending in a specific
>goal, of the expected progress of the project.
>(The bigger the project, the
>less value that is place on the timeline as an >absolute, and more a rough guide.)
This needs to be done first. A draft should be written, then submited for approval from the entire develompent staff.
If we wish to get anywere. This will put the project on track.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
(Note: This message was originally sent to xpl2. He suggested that I post it here, so that is what I am doing. Alot of what is in here is personal experiance.
Comments, suggestions or whatever is EXTREMELY welcome, and encouraged.)
Well, there has been two days without any posts on the boards, so I am going
to write this dorectly to you. First, as I posted on the board about an IRC
server. I can get one set up for all of us to meet together on and discuss
things. I think it be the best way to go about it, personally, as everyone
has (access) to an IRC cliet, the bandwidth used is quite minimal, the
machine power that is needed is quite minimal and I think it is quite easy.
Secondly, I have a few ideas I would like to share with you at the moment,
as at my prior company, I was the project leader for a new extension to our
corporate web site. I know that you are the guy in charge, when it comes to
this particular project, but I just wish to relay some of the things I have
seen/known to work.
1. Define a Project Abstract. All that this is a document that defines some
key points/goals/etc. of the project. Primarily intended audiance, goals and
a timeline. The timeline should logical divisions, ending in a specific
goal, of the expected progress of the project.(The bigger the project, the
less value that is place on the timeline as an absolute, and more a rough
guide.)
2. After that is done take the first logical division and determine what is
needed to meet that particular goal. This will usually include sub projects
that have their own individual goals.
3. Determine the skill set(s), stengths/weaknesses of each group
contributor, and most importantly, find out what subproject(subgoal) of the
first logical division most interests them. (Proven fact that people do a
better job when it is something that they like.) Group the people together
and designate one as a project manager.
4. Set a date that each subproject MUST be completed by. (This I have found
is a good technique, making a HARD, SOLID date. I am not saying that the
date is the date it must be completed or else, but the *impression* that it
is the date it must be completed. I once told some of my reports under me to
get me something in a couple of weeks, well it turned out to be a couple of
months. When I gave them a date (and a reasonable date at that, I got it in
on or (in MOST cases) before that date. If more time was needed, I granted
it, but still set another date.) This needs to be discussed with the project
manager (and possibly their whole group) also, to make sure it is
reasonable.
5. Have each project manager assign a timeline and such for their indivdual
project. (Basically they follow steps 2 - 4 for their subproject.
6. Set up a mailing list for each subproject, and the logical division. (I
could look into it, if this is something you wish to do)
7. Encourage the project manager to have regular meetings (IRC?) with their
group. (Every week or two, or what they feel is appropriate.) Have regular
meetings with the project managers. (Every two weeks, month, or whatever is
appropriate.)
8. For the most part, stay out of the subprojects, and leave them alone,
except for the ones you (the whole project's manager(s) admin(s)) are
directly involved in, request for assistance or are faltering.
Thirdly, I think it may be a good idea to do an Ask Slashdot. Something of
this nature, maybe: A new distro is being created... What do the readers of
/. feel the target audiance should be, what is lacking in other distros,
what is good in other distros, what can/needs to be improved. Something
like that, I think would generate huge amounts of ideas and get more people
to join Maximum Linux.
Fourthly, it may prove benificial to incorporate Maximum Linux into a
non-profit, for serveral very important resons: (Don't quote me on all of
these, I am not an MBA or a lawyer.)
1. Corporate Shield -- Something goes wrong, you nor the developers can be
held personally liable.
2. Volunteers -- (Don't quote me, I am not positive) For-profit companies
cannot, except in special circumstances, have volunteers.
3. Donations -- (again, don't quote me, I am not positive) For-profit
companies cannot, except in special circumstances, reeceive donations.
Being a non profit, you could for instance, request VA Linux donate a system
(or whatever), they would be able to get a tax break from it, making them
more likely to do so.
AFAIK, a non-profit must take all clear proffit (after bills, salaries,
debts, etc have been paid) and put it back into the company.
These are just my thougts, that I have learned over the years, and wish to
pass on to you. You may already know this and I wearing out my keyboard for
nothing, or you may not, and it has give you some ideas. At any rate I am
quite ready to help with the project in what ever way you see fit, be it a
secondary admin, a project leader, a developer, whatever, please let me
know.
I like the idea of an IRC server. We could also consider getting a registered channel on OpenProjects. We *will* need a place were we can chat in realtime, else this project won't move efficiently.
I think that what you are suggesting is just general good practice.
I'd also be interested in the IRC / whatever other services you see fit to offer. Sounds like an excellent idea!
IRC is definitely a good idea...something we should be doing as soon as possible. I think the /. idea is an excellent idea in terms of exposure and eliciting participation from the community.
--good to see someone thinking ahead
--dave
IRC is definatly a bad idea.
It assumes everyone can be on at the same time.
The internet is a global medium. I for one am not getting up
in the middle of the night to be entertained by horibla spelling of off the cuff remarks and banal chatter.
Writing email , or even forum postings, forces one to THINK
before posting.
I really have to disagree. Not everyone has to use it, but for those who wish to use it, it is there. Like all good things, it is an option for people to use if they want/feel the need to.
Looks like IRC is free for 30 days...shareware. I'm not excited. Use yahoo chat or something like that if you really need it.
Ravi
IRC itself needs no license at all. Maybe some
of the IRC clients do, but what the heck - use another one, there are plenty.
ircii, xchat, ....
ERIC
well, there is one thing that would be nice.
Every distribution thinks they have the better way, and all of them flow away from the linux standards that we all want.
there is a file at
http://www.ibiblio.org/pub/Linux/docs/fsstnd/
that gives the linux filesystem STANDARD which every distribution seems to warp their own way...
you would have me on board definately if this was one of the major aims of this distribution.
peace
>Define a Project Abstract. All that this is a >document that defines some
>key points/goals/etc. of the project. Primarily >intended audiance, goals and
>a timeline. The timeline should logical >divisions, ending in a specific
>goal, of the expected progress of the project.
>(The bigger the project, the
>less value that is place on the timeline as an >absolute, and more a rough guide.)
This needs to be done first. A draft should be written, then submited for approval from the entire develompent staff.
If we wish to get anywere. This will put the project on track.