[kdewebdev-site] First draft of www.kdewebdev.org vision statement - feedback requested

[David Joham]

Hi Eric, 

Please see in-line comments below.....

>
> Omigosh! Less than an hour to say this is all wrong... ;-)
>

New plan. Everyone else has a week. Eric gets 35 seconds from receipt of RFC 
Emails :)
>
> A primary objective of kdewebdev.org is to manage growth in the CVS module.
> As the project grows the developer noise load and project complexity
> increases. A chief aim is to anticipate user concerns to divert "noise" as
> well as provide a central cohesion, focus and clarification to the
> development process. The developer support will both assist developers and
> inform users.
>

The growth of the CVS module is a Phase II thing. In order for us to get 
started and get some momentum, we're going to get Phase I off the ground 
first. After we've got the design and coding going, then I'll start doing the 
vision plans and what not for Phase II.

This will allow us to work in parallell - one team doing implementation and 
another doing designs for the next revision. I plan on Phase II being 
considerably more complicated to design than Phase I. For example: what is 
this "driver noise" that you speak about? How are we going to go about 
"providing a central cohesion, focus and clarification to the development 
process?"

In order for us to build a successful Phase II, all of these things will have 
to be fleshed out and written down. Otherwise, we'll never really know what 
problems we're trying to solve, or if we solved them. 

The nice thing about having such a good team is that I can turn them loose on 
Phase I (once we're finished with the design) while I concentrate on Phase 
II. Hopefully, Phase II design will be finished by the time we're finished 
with Phase I implementation.

> I'll leave it to David to repackage that with his statement as he sees fit.
>

How'd I do :)

>
> As I see it the size and complexity of the developer.kdewebdev.org portion
> of the site is rather substantial.

Agreed

> As it stands right now my initial 
> conversations have me with the understanding that I will be laying out the
> infrastructure for this because of my somewhat unique qualifications. 

Infrastructure == assistance in vision and design in the beginning. 
Implementation is possible depending on time and team resources when we get 
there.

> This 
> will be somewhat separate and merge in. At some point it would become a
> more clear development path driven by it's data structure. 

Hate to harp on this point, but the clear development path has to start with 
vision and high level design documents, not code. Otherwise, you're not 
offloading anything from yourself since you'll be the only one who 
understands what's going on. It's *much* easier to get started as a developer 
on a site by reading design documents than looking at a database diagram. :)

> As this will 
> probably at least initially fall to me that may be why it doesn't appear
> here. I'm okay with that and just trying to interact without being a "bull
> in a china shop". It seems like this would be a concurrent Adjunct to Phase
> I, or Phase IA.
>

The implementation will be Phase II. The design and vision will be concurrent 
with Phase I activities.

> If David has input here or anything I've missed I'm open to it. Also I
> assume at some point people involved with the rest of the project may be
> involved. 

I plan on handing out high-level design assignments next week. Hopefully, 
early next week.

>
> I'm also open to just functioning as a subproject developer lead under
> David's direction with the idea that I just want to achieve some particular
> functionality. I'm open to that being externally defined and reviewing and
> revising it too.

You will be the primary SME (Subject Matter Expert) for the 
developer.kdewebdev.org section of Phase II. The only difference is that 
you'll get less time to review things (see above) :)

>
> I like the description and thinking here very much. My point so far has
> been largely to address the apparent exception of developer.kdewebdev.org,
> which we discussed on the phone, for clarification purposes.

Point taken. 

> Interestingly, in my original thinking I had looked at adding live
> interaction interfaces to Quanta... but I had not actually thought through
> the idea of individual tool resource submission. Ideally Quanta moves to
> push button ease, but this is a very nice follow through as suggested. Good
> thinking David.

<blush emocticon=":)">Awww shucks</blush> 


Thanks for your comments Eric. I think we're pretty much on the same page.

I have to go now. It's a busy Easter weekend.

Best regards,

David