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

[Eric Laffoon]

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

On Saturday 10 April 2004 8:43 am, David Joham wrote:
> 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 :)

I was afraid that might happen. This new guy is really tough. :-/
>
> > 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?"

I need to answer this when I'm not so tired, and now that I think about it I 
have new ideas for what we have... for instance...
* Red Hat released 3.0pr1 in 8.0 which was a disaster
* 3.1.4 had a serious delete bug in it
* Mandrake's 10.0 community release has a bad CVS snapshot
Each of these "incidents", be they an accident on our part or less than 
spectacular judgement from a distribution, creates "noise" for us answering 
repetitive emails and doing damage control. Also we can see by the age of 
them they become less relevent with time but highly relevent when they are 
first discovered. Clearly we need to do two things:
1) Disburse important information for easy assimilation by users, including 
smaller issues like little fixes that come up on mailing lists. Also this 
needs to have a maintainer.
2) We need to actively do damage control. For many that have binary 
distributions they have a subjective opinion of our product that can be 
donwright terrible! We need to be able to point them to a page, and frankly 
stick distributions, that have done less than good things, feet to the fire. 
We should seek to control our reputation and destiny.

All of this is far more practical when we have a dynamic and thriving site 
with news and tips and probably forums and more, but the key is that we 
should preemptively disburse information about problems as soon as we are 
aware. This needs to be high profile and we can respond with nothing more 
than a link if we get mail bombed. ;-)

This is a step in the right direction, a big one.

For the development process, I need to go through my email archives as I've 
posted numerous emails to the lists on this. The key is that we will be 
further defining what we're doing and merging the list management with a web 
based back end for tasks that developers will all have the ability to log in 
to and update information... what they're doing, want to do, want other 
developers to help on. There is also the developer mentoring program I 
mentioned. Because I think I covered this so well I'll fish in my gazillion 
emails...
>
> 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.

That's great. I was under the delusion you were going to make less work for 
me. ;-) Now I actually have to define things. The frustrating thing is how 
many times I've done that and my ardent wish to stop repeating it and have it 
zapped into existence.. (sigh)
>
> 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 :)

Good. Since I already know what I have to do all I really need is to have 
someone hit me with a blunt instrument with a rhythmic pace until I complete 
it. ;-)
>
> > 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. :)

Yeah, well... I was primarily thinking of the database layout since I'm very 
good with it. Once it's defined it's pretty much done and I hadn't planned on 
farming out the account there. So from that point I was going to produce the 
detailed descriptions, probably 70%-80% of that is already done in developer 
list emails.
>
> > 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'm all warm and fuzzy all over. I just need to know when I can have a 
vacation. I have a good feeling about 2008. ;-)
>
> > 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.

Me too, just that I'm asleep and drooling on it. ;-)
>
> I have to go now. It's a busy Easter weekend.
>
> Best regards,

You too!
>
> David

- -- 
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)

iD8DBQFAeLH6SiV5TqRTAEsRAs+tAKCbRJFpdCdz9oXj4t2OW/EAutK/JQCfRWp1
BynCBSsBY5n2CB3RmlERAoY=
=kNpD
-----END PGP SIGNATURE-----