[kdewebdev-site] Welcome to the site project

[Bill Chmura]

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


Okay, I am back and we are just about ready to get started...

There are few people who I still need to get onto the list and then we are 
going to get started and build some web sites.

I am particularly excited about this project because it is a nice change of 
pace...  Professionally I manage web, software dev and implementation 
projects but this will be the first open source project I have managed.  I've 
worked on a few, but not run them.  I see the difference primarily as being 
that while there is no paycheck hanging in the balance for you, you actually 
do want to be here.  

I don't want to get into it to much till we get the last few onto the mailing 
list.

Thanks

Bill



On Tuesday 24 February 2004 10:15 pm, Eric Laffoon wrote:
> 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. ;-)
> ===

- -- 

Bill Chmura
Director of Internet Technology
Explosivo ITG
Wolcott, CT

p: 888.560.YWEB (9932)
e: bill at Explosivo.com
w. http://www.explosivo.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQFAQOYpEEA64RcvcRERAqPqAJ9M5ZO6xSHNG9Mfn3i9m8GnP3FE8QCeLObb
B8gaHlPMV7cFmGJHtuorxGw=
=4qeK
-----END PGP SIGNATURE-----