[kdewebdev-site] Welcome to the site project

[Eric Laffoon]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi all!
Welcome. I want to thank everyone for their interest and involvement, and 
especially Bill Chmura for bugging me on this as well as Chris Hornbaker for 
being very motivated here.

Currently we have subdomains set up on site for
* quanta.kdewebdev.org
* kommander.kdewebdev.org
* kimagemapeditor.kdewebdev.org
* ksxldbg.kdewebdev.org
* kfilereplace.kdewebdev.org
* developer.kdewebdev.org

I plan on setting up CVS Wednesday and that is basically our go point. 
Everyone will need to get me a user name and passwordand I will need it in an 
ENCRYPTED email. If for some reason this is not possible there is always the 
phone. The reason is very simple... the site will be accessed with fish or 
SSH. CVS will be accessed with pserver and SSH. Everything is secure. As a 
matter of practice (and because I host my business on the same server) this 
is 100% non negotiable. If I have to use unencrypted passwords then the user 
must login and change their password immediately. That means I have to police 
this. So we go for encrypted emails. Currently only the kdewebdev mail server 
is temporarily unable to do SSL. I expect to have Jabber set up soon as a 
closed list.

While I will be the admin Bill Chmura will run the development plan. That's 
good for me because it's one less thing to be buried under. Anyway, Bill, 
please send me a list of who you have talked with. Everyone else please send 
me an email requesting an account on the server. This will give you both CVS 
and write privileges. I don't want to have to futz around too much to 
restrict write privileges so let's check into CVS and then follow policy as 
Bill says... or in the event I freak out I'm sure you can figure that one 
out. ;-)

Below is a repost of what I posted on the developer list with some ideas of 
what I want to do with the developer section of the site. We will have a 
developer section, user support and application sections focused on 
introducing things. As Bill seems busy, from our phone call we agreed to 
first lay some foundation for how we will abstract data from format. The 
guideline is first and formost to have an intelligent back end that's easy to 
maintain. As far as artwork we will be using sound CSS layout and we will 
have a graphic artist take our work and create our look, which we will 
dissect and embed in CSS. 

It might be good too if people look to handle either aspects of the site or 
sections. But I'm stepping on Bills toes here and I agreed to let him lead 
the charge... so I'll shut up. ;-)

Here's the repost.
===

TACTICAL OVERVIEW
I will announce this only on the developer list now and will announce on the
user list when we are ready to proceed. Those people involved in prodicing
the site will have:
* a CVS account for the site repository
* a shell account to upload with
* a subscription to our web site development list
* a Jabber account on a private server for development
Quanta developers who will be active in leading sub projects will also have
account access to update project related information. This access will most
likely be to a password protected area to upload, edit and delete description
information either in a database (my preference) or a wiki. The key aspect
here is that project information will be available to users, but only
editable by developers.

STRATEGIC OVERVIEW
Without going into a lot of detail that has been done about who does what in
the design, how content is handled, etc. I want to cover specific things that
will be on the site. First the obvious:
* Introduction to Quanta for those new - description, screen shots,
testimonials
* Information for users - News, FAQs, Hot items from lists (for this question
refer to this link), development information, etc...
* Information for developers - links to KDE info, basic Quanta design info,
hot items and answers from the developer list.

Obviously the above will require at least one person from the developer and
user list to be inputing the information on hot items. That or we set up a
key code to put in an email to make it hot and run a cron job to harvest the
list daily.

NEW CONCEPTUAL IDEAS TO IMPLEMENT FOR DEVELOPMENT
There are a number of new ideas that have been coming to me and that I want to
incorporate. Frankly the Sourceforge model in my opinion just doesn't cut it
and seems like trying to suck honey through a straw. These are ideas that I
think will help to really take Quanta to the next level.
PROJECT ORGANIZATION CHART
Who does what where and who takes responsibility. I neither can or want to
take control of every detail in this project, but someone coming in doesn't
know who does what. By identifying that person on site we can help put a face
on our team and effort as well as improve a lot of things.
* List areas with someone leading them
* List areas needing someone to lead
* List who is working in a given area
* Allow sub project leaders to post requests for people and tasks
* Enable new developers expressing interest in an area to hear from the
respective lead people
PROJECT DEFINITION TASK LISTS
We need to better define what needs to be done. Our current list is inadequate
and due to sourceforge limitations it's too difficult to have everyone keep
up. Here's the new proposition:
* Tasks, sub tasks and wish list items that are brought up can be entered in
to a queue and displayed. Those items can receive priority scale votes from
developers and task leads. Optionally they could be farmed out to user polls
too. Project and task leads can then add these to the do list items taking
popularity and other factors into account.
* Do list items can reflect multiple sub project leads and and each can then
do their own do list items. A do list item is a Task. A task will have a
person who leads that task and anyone else who has to do something listed
along with them. Elements of things that have to be done, attributes that
need to be included or excluded can be listed in a sub task and assigned to a
developer.
* Tasks and sub tasks will have target dates. They may be set to fire off an
email to the developer on that date. If they are stale by a week they can
fire off an email to task leaders, sub project leaders and project leaders.
Since the developer sets the schedule it is their timing. Tasks can also be
set with relative timing to dependent tasks.
* Developers will be able to log on to the site via SSL to their account.
There they can see the status of all their tasks and sub tasks. If they lead
a sub project they can review the status of that too. Everything will be
quick and easy to do and you will only be able to change what is in your
chain of responsibility.
* Users will be able to visit read only reporting on these do list items and
tasks. They will be able to make suggestions to leaders keyed to specific
areas. Users will be required to have a user account and will be able to see
any changes to their key points of interest. Leaders will see user references
when they log in.
DEVELOPER ACCLIMATIZATION PROGRAM
When new people join our developer list they will express their interest in
specific aspects of the project. That will allow those leads to interact with
them and help them get up to speed. Additionaly we should have a Developer
Mentor program. This is because I get a varying amount of interests but most
will not take the next step to join the developer list. We have over 60
people subscribed to the developer list and while some are packagers or
observers the vast majority become lurkers. We need higher ratios of interest
to involvement and involvement to action. I believe that Quanta could easily
have 20-30 active developer by mid year. Right now we have maybe a dozen and
about half that submitting much C++. Here's my plan to turn this around
completely:
* New developers on the list go into a new developer list. Those developers
who have signed on to mentor and who show open will receive an email from the
system that a developer has joined with a link to their info.
* New developer info will show their areas of expertise and their areas of
interest in the project.
* A developer can accept the task of mentoring the new developer and send the
new developer an email welcoming them to the project. This will be a bonding
process where the developer helps the new developer to feel comfortable and
to overcome the internal resistance to actually bringing forward product.
* Developers can register to mentor from 1-4 developers at a time and the
mentoring period is set to 2-4 weeks. The idea is personal involvement to
bring that developer in out of the lurk. ;-)

Let me conclude by saying this. As I see it the biggest problem we face right
now has to do with dealing with the size of this project and it's details.
What I've proposed is not small but it can largely be doveloped by a few
developers and a number of users. It addresses:
1) keeping track of the little factors and what's happening
2) how to increase the number of people carrying the load

I dont think this project is in any way seriously flawed, but it has huge
potential we are not reaching. I believe these ideas hold the key to creating
a true phenomenon on FLOSS. If we could put on 4-6 active developers a month
we could reduce strains on current developers, expand feature efforts and
improve testing and quality.

As usual this is open to discussion, and the key factor here is a small
additional effort from developers up front reduces the actual load over time.
I'd like to thank Bill Chmura for constantly bugging me about getting going,
Andras for doing everything under the sun and Nicolas and Chris for
accidentally getting me thinking about the mentoring idea. ;-)
=== 
- -- 
Eric Laffoon - Quanta+ Team Leader 
http://kdewebdev.org  eric at kdewebdev.org
Mailing list - http://mail.kde.org/mailman/listinfo/quanta
GPG Fingerprint: 48FB 218D 747F A54A 319D EE98 4A25 794E A453 004B
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFAPBM9SiV5TqRTAEsRAhGPAJ9sArJr4qo0HHAgn0WWjk4Z0uDBhACfcWHi
VYvQeMaO/9gTzpLJct3MTmc=
=gnGp
-----END PGP SIGNATURE-----