The Fine Print: The following comments
are owned by whomever posted them.
( Reply )
|
Re: development strategy
by James Richard Tyrer on Saturday 24/May/2003, @15:47
|
> Actually quite easy: who codes[:] decides
That is what I thought, but didn't want to be so arrogant as to say it.
There is nothing wrong with the Maintainer making the final decision.
The problem I have is that this may also mean:
'who codes: designs'
which is not good. It is just something that I learned in engineering school that discussion of a designe with other engineers always leads to improvements. Specifically, in trying to explain something to someone else, you learn about it. Sort of the reverse of the Socratic method of teaching.
|
[
Reply To This | View ]
|
Re: development strategy
by ac on Saturday 24/May/2003, @15:57
|
Maybe you should learn from Eric Laffoon. Look what he achieved with Quanta Plus by being behind many of the design decisions and sponsoring.
|
[
Reply To This | View ]
|
Re: development strategy
by lit on Saturday 24/May/2003, @16:52
|
> It is just something that I learned in engineering school that discussion of a designe with other engineers always leads to improvements
Yup, I agree.. but this is not ALWAYS needed. Most of KDE, imho, is too trivial architecturally to be implemented in more than one method. Sure, improvements could be made, but gains would be marginal at best.
Instead, perhaps you could focus on non-trivial things such as khtml, kdelibs/kdecore (most of kdelibs/kdeui is pretty trivial wrappings/extentions of Qt classes), and perhaps even Qt itself. Large apps such as koffice and kdevelop would also benefit, of course.
Note that there is plenty of predicience in KDE's history to support this fact. For example, kparts, which was largely implemented initially by Torben Weis back before KDE 2.0, but only after a large amount of discussions on kde-devel, which resulted in many ideas/proposals that were shot down before Torben came out with kparts.
Most of the freedesktop.org has also been developed in this matter.
|
[
Reply To This | View ]
|
Re: development strategy
by AC on Saturday 24/May/2003, @17:53
|
>>Instead, perhaps you could focus on non-trivial things such as khtml, kdelibs/kdecore (most of kdelibs/kdeui is pretty trivial wrappings/extentions of Qt classes), and perhaps even Qt itself. Large apps such as koffice and kdevelop would also benefit, of course. <<
But here, again, all discussions are useless unless somebody wants to do the changes. Feel free to discuss changes when you want to improve it. But when you are not going to do it, such discussions are just a waste of time...
|
[
Reply To This | View ]
|
Re: development strategy
by AC on Saturday 24/May/2003, @16:57
|
Yes, and quite often developers discuss their ideas with other people on the project's mailing lists or on irc, telephone, in real life and so on. Who says that this doesnt happen?
|
[
Reply To This | View ]
|
Re: development strategy
by James Richard Tyrer on Saturday 24/May/2003, @17:55
|
> Who says that this doesnt happen?
I am not saying that it doesn't happen.
I was only saying that it should happen.
What I was advocating on the KDE-Development list was that a suggestion box list might be a good idea -- where ideas could be discussed better than using bugzilla for that. Some of the negative comments there indicate that a seperate list would be a good idea since some of the developers are not interested/do not have the time for this. And, some of the KDE-Development list is requests for help.
|
[
Reply To This | View ]
|
Re: development strategy
by anon on Sunday 25/May/2003, @00:42
|
So you are another one of the mass of people who have oh-so-good ideas, but unlike the majority you imply that you are right because of your precious degree?
You want a suggestion-box list - maybe you should look at the kde-usability list archive? Such "suggestion" lists might work for smaller projects, but with KDE there is so much to suggest, and so many people who think they have a suggestion worth of sharing with the rest of the world, that it becomes impractical.
Do yourself a favor, distinguish yourself from the rest and actually submit a patch. And please, save us from your "I'm sick and thus have an excuse not to contribute anything but ideas, but I have degrees and thus you need to listen" attitude. I recently had some serious health problems as well, which temporarily rendered me unable to use a computer. but unlike you, I realized that submitting my ideas (and trust me, I have a shitload of them) does not make much sense because the KDE folks already get enough of shallow suggestions, without actually implementing your proposal and attaching a patch, your suggestions will drown in the masses.
Maybe you should start your "What James thinks is right" list and all the people who care could subscribe there.
|
[
Reply To This | View ]
|
Re: development strategy
by James Richard Tyrer on Sunday 25/May/2003, @13:38
|
Notice the methodology of the anonymous troll.
Deliberately misunderstanding what is said so that it is easier to ridicule it.
And specifically making use of a common logical fallacy.
all S is P -> all P is S
He takes as his first assumption that everything that I said is wrong and just finds ways to support his conclusion.
I did not even mean to suggest that I was always "right" because of my "precious degree".
I digress to state what all non-trolls should know: that a degree is "precious" because of the work needed to earn it and for no other reason. I mentioned my "degree" not because I expected people to accept everything I said because I expected everything I said to be accepted, but because I was tired of having anything I said dismissed with one line by some 'arrogant developer'.
The actual issue is where suggestions should be posted. Currently, many of these suggestions are posted to Bugzilla as 'wishlist' items. Many of these need some work which could be achieved by discussion. Many of them are useless. But what all of them do is clog up Bugzilla. Is this a good thing? Is it better than having a list for such suggestions?
> Do yourself a favor, distinguish yourself from the rest and actually submit a
> patch.
I have submitted patches. I helped fix two bugs with the current Ksplash. I submitted a patch for the: 'startkde' script, but nobody on: kde-devel was interested in discussion of it.
> And please, save us from your "I'm sick and thus have an excuse ...
It is the simple fact. I am available because I am retired on disability. The project can accept that or not.
> KDE folks already get enough of shallow suggestions, ...
Exactly, and they clog up Bugzilla. But with a suggestion-box list, they would either be worked on till they were usable or they would be discarded.
|
[
Reply To This | View ]
|
Re: development strategy
by JohnFlux on Sunday 25/May/2003, @21:55
|
Sir,
Perhaps you should look at why people seem to quickly attack you.
One of the best pieces of advice I got was from one of my lecturers at university, who said that the trouble with students, is when they get their first job, they immediately start trying to fix all the problems.
JohnFlux
|
[
Reply To This | View ]
|
Re: development strategy
by James Richard Tyrer on Tuesday 27/May/2003, @20:32
|
Yes, John.
But, that *is* what engineers do. It is what they are trained to do.
Find the fault.
--
JRT
|
[
Reply To This | View ]
|
Re: development strategy
by Datschge on Sunday 25/May/2003, @12:46
|
> What I was advocating on the KDE-Development list was that a suggestion box list
> might be a good idea --
No, that would be a very bad idea, there are way too many places where you can give suggestions already. Nobody can keep track of all of them, and adding yet another one won't make that any better. Bugzilla on the other hand is centralized.
> where ideas could be discussed better than using bugzilla for that.
Bugzilla is actually the ideal place since where else can you get other people to vote for your ideas, where else are all suggestions easily searchable as soon as someone intends to implement it, where else does a message or a patch not get lost?
> Some of the negative comments there indicate that a seperate list would be a good
> idea
I count 81 mailing lists alone at lists.kde.org and quite some more mailing lists which are managed with pipermail instead mailman and such don't appear on lists.kde.org, you gotta be joking saying a separate list would change anything.
> since some of the developers are not interested/do not have the time for this.
As pointed out many times already in the discussions you started: why discuss something if in the end there's nobody to implement it? Only code or other actually usable contributions count in the end, everything else simply is hot air. Get over this simple fact.
|
[
Reply To This | View ]
|
Re: development strategy
by James Richard Tyrer on Sunday 25/May/2003, @13:52
|
> As pointed out many times already in the discussions you started: why discuss
> something if in the end there's nobody to implement it? Only code or other
> actually usable contributions count in the end, everything else simply is hot
> air. Get over this simple fact.
Thank you, it is good to know that. :-)
So, it is my understanding that I should abandon my efforts to go through the large number of bugs clogging Bugzilla because this isn't a useful contribution.
|
[
Reply To This | View ]
|
Re: development strategy
by AC on Sunday 25/May/2003, @16:16
|
No, everybody here agreed that working with Bugzilla is great. It allows discussions, and even better: the maintainers of the application get all comments, unlike mailing lists that are not read by many maintainers.
|
[
Reply To This | View ]
|
Re: development strategy
by Anonymous on Sunday 25/May/2003, @14:44
|
You're wrongly mixing up relation and functionality of lists.kde.org<->mailman and pipermail.
|
[
Reply To This | View ]
|
Re: development strategy
by Datschge on Monday 26/May/2003, @11:10
|
Yes, please educate me. =) Nobody on the Nove Hrady mailing list seems to know why it doesn't appear on list.kde.org. And additionally the navigation style of the archive imo sucks compared to the style used in seemingly all mailing lists at list.kde.org. So again, please educate me since I'd love to know the problem to be able to solve it. =)
|
[
Reply To This | View ]
|
Re: development strategy
by ik on Tuesday 27/May/2003, @15:58
|
i think you will have to prove that whatever (code or strategy) you come up with will work good, better than the current code/strategy in the current situation.
and arguments like "its documented in CS books" don't count, you will have to explain why something will work better (not in the common case but in the KDE case). if you can convince enough coding people it will work better, your ideas will be taken into account.
offcourse its difficult to get concrete convincing arguments for a development strategy, because you will have to show that switching is worth it: you will have to show that advantages are significantly more important than disadvantages.
your comments sometimes can be interpreted (don't know if you meant it) "trust me, i DO now about that because ...". That won't convince anyone, in contrary ...
|
[
Reply To This | View ]
|
Re: development strategy
by James Richard Tyrer on Tuesday 27/May/2003, @20:28
|
Yes, you make a valid point. That is why discussion is so important. But, we don't have discussion.
Discussion is: "tell me more about this, it might ... "
'Arrogant Developer' is: "go away, you are wrong and I don't want to listen anyway" :-)
Which do you think is better?
I'm not going to say that "its documented in [a] CS book" although I might say that there was an interesting article in Communications (of the ACM) about this. -- you do read that, don't you?
No, I am NOT saying: "trust me, i DO know about that because ...". If that is what you think, you have not understood. What I am saying is: 'listen to me, I *do* know something about CS ...'.
|
[
Reply To This | View ]
|
Re: development strategy
by Ingo Klöcker on Wednesday 28/May/2003, @00:59
|
Did you already think about giving a talk at Nove Hrady? After all the Call for Papers says:
"Do you want to present a particular programming pattern, a tool, a development strategy, or anything else that helps KDE developers become more productive?"
|
[
Reply To This | View ]
|
Re: development strategy
by ik on Wednesday 28/May/2003, @03:56
|
> No, I am NOT saying: "trust me, i DO know about that because ...". If that is what you think,
> you have not understood. What I am saying is: 'listen to me, I *do* know something about
> CS ...'.
ah ok. i don't think that will convince people to listen either. And i think its unneeded, its not because someone flames you down that your message was read by nobody.
the difficult part is that the "arrogant developer" doesn't have to prove you are wrong, but you have to prove that you are right (especially if people don't know you). I think that is perfectly normal.
you also cannot expect others to do work for you when they are not convinced, sometimes they won't even give you information about the current situation (if that's what you mean). Your challenge is then to use your own knowledge/resource/time to find information and arguments yourself ...
in short, i think if you come up with a very concrete "look, now we do it that way, and its better if we do it that way because ..." you will be heard.
saying 'i think A works better than now, but i don't know about now, so please explain me so i can start a discussion' will not work ....
|
[
Reply To This | View ]
|
Re: development strategy
by ik on Wednesday 28/May/2003, @04:06
|
i think i can summarize it like this: in an opensource world you can take less for granted than you did in CS world. So you have to do your own research more, even for stuff you were taking for granted (like a development strategy). And that research should come before serious discussion.
|
[
Reply To This | View ]
|
Re: development strategy
by ik on Wednesday 28/May/2003, @04:39
|
ok replying to myself again. i think your 'research' could look very vaguely like this (its just an idea, its not an outline or so)
* what do you want to propose.
- what are the documented advantages ?
- what are the 'building blocks' ? (eg: a building block could be the fact you can give developers assignments).
* the KDE community.
- investigate how it works, what are its properties
("soft" that can be changed if its really worth it, and "hard" that cannot be changed at all)
- and what is the current strategy.
- are those building blocks still present in the KDE community ?
- are those documented advantages still advantages for KDE ?
- which advantages does your thing have that the current strategy doesn't have ?
- which advantages does the current strategy have that your strategy doesn't have ?
- try to predict which advantages will be seen as significant by the community, and which won't.
* adapting
- see what you can achieve (you can only change some things, and you cannot change too much)
- try to see if you can reach the advantages with the least intrusive change
|
[
Reply To This | View ]
|
Re: development strategy
by James Richard Tyrer on Thursday 29/May/2003, @01:55
|
OK, I see your point. Although this isn't the way I am used to working,
I will try it (again) with another posting about the outdated font stuff (which doesn't work with current software) in the: "startkde" script.
--
JRT
|
[
Reply To This | View ]
|
|
The Fine Print: The previous
comments are owned by whomever posted them.
( Reply )
|
|
![[KDE Dot News]](http://www.kde.org/dot/Images/kdedotnews.gif)
