[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-www
Subject:    Re: Development
From:       Marcos Fouces <mfouces () yahoo ! es>
Date:       2005-04-05 7:10:48
Message-ID: 200504050910.48780.mfouces () yahoo ! es
[Download RAW message or body]

On Tuesday 05 April 2005 03:24, Carlos Leonhard Woelz wrote:
> On Monday 04 April 2005 03:45, Marcos Fouces wrote:
> > On Monday 04 April 2005 06:53, Carlos Leonhard Woelz wrote:
> > > The problem with specific jobs (non general tasks) is that someone has
> > > to maintain the lists of available tasks. The developers do not want to
> > > do it (I don't blame them: let them code).
> >
> > This is exactly why i purposed to create a webteam: to avoid devs dealing
> > with those issues.
>
> Hmmmm, I don't agree here. To keep tha status updated, you need specific
> knowledge of the module / application. 

Yes.

> It is a job for the (theoretical) 
> quality team of that module / application or for a developer who knows the
> answer. To require the webteam to keep them updated, it is just too much
> work.




>
> > > I maintain (well, at least
> > > used to, and intend to update) the task pages for kdepim. It is done on
> > > the wiki, to make it easier to change. It worked for some time, until I
> > > stopped working on it, and it really attracted new volunteers. But you
> > > have to know the applications involved and the tasks. See the quality
> > > page to see what I mean:
> > > http://wiki.kdenews.org/tiki-index.php?page=Quality+Team+KDE+PIM
> >
> > That's a good starting point but is too tedious to introduce changes by
> > hand. I think is better using a database and a litle PHP, something like:
> >
> > - http://savannah.gnu.org/people/?group=tasklist
> >
> > It should also be posible to extract jobs by category, by team, by app...
> >
> > > From my personal experience, a page like jobs.kde.org won't work,
> > > unless:
> > >
> > > 1) It is a epository for general "jobs descriptions with requirements"
> > > like the quality page: http://quality.kde.org/develop/modules/
> > > and / or
> > > 2) It is a general framework for volunteers to add updated info about
> > > apps and tasks.
> >
> > The first point is already done, i said that on a past post, but not the
> > second...
>
> OK, let's be constructive here: if you create a nice system, I will use it,
> and drop the wiki pages. But it must allow people to say "I take this job"
> and put their names there, and maybe update it without cvs access. Now it
> looks like a wiki :) , or not?

No, there is nothing to do with a wiki. I am thinking in something like this:

if ($members_betatesters_konqueror==0) {

 echo "Nobody is betatesting $kappname, you're welcome to help";

 } 
	else 
		{
 			echo "There is some people betatesting 
			$kappname, exactly $members_betatesters_konqueror"
 		}


We could have a global view of what help is needed and where in a manner that 
a wiki cannot. We could ask database with any criteria we like for example:

- In the doc team, a table with every official doc of KDE and his/her 
mantainer. If there is no maintainer, the cell could appear in red with the 
legend "Get Involved"

- In an aplication homepage, we should represent in a table every task needed 
by the app (doc maintainer, developers, promo, betatesting...) and the 
current maintainer of each one (if any).

Of course a single person can be the mantainer of several tasks.

This database (a sort of "KDE Human Resources") could also be used in 
people.kde.org and in worldwide.kde.org (or the likes) as it contains all 
info of active members.

Sorry but i didn't see any paralelism with a wiki.

Perhaps my bad english....


-- 
Greetings from Spain
Marcos Fouces
_______________________________________________
kde-www mailing list
kde-www@kde.org
https://mail.kde.org/mailman/listinfo/kde-www
[prev in list] [next in list] [prev in thread] [next in thread]