The KDE Developers' Conference is a meeting of KDE contributors from
all over the world. It will feature three days of technical talks and
tutorials. Do you have a particular expertise related to KDE programming that
could be useful for your fellow developers? Do you want to present a
particular programming pattern, a tool, a development strategy, or
anything else that helps KDE developers become more productive? Then
consider talking about it or giving a tutorial at the KDE Developers'
Conference.
KDE Developers' Conference - Call for Papers
August 23th to 25th
Zamek, Nove Hrady, Czech Republic
Conference Program
The KDE Developers' Conference is a meeting of KDE contributors from
all over the world. It will feature three days of technical talks and
tutorials. Following the conference there will be some - albeit
limited - opportunity for interested groups to gather together in
computer labs for a hacking session until the 31st of August.
Besides, there will be plenty of time for socializing.
More information is available at http://events.kde.org/info/kastle
Do you have a particular expertise related to KDE programming that
could be useful for your fellow developers? Do you want to present a
particular programming pattern, a tool, a development strategy, or
anything else that helps KDE developers become more productive? Then
consider talking about it or giving a tutorial at the KDE Developers'
Conference.
We solicit submissions for presentations and tutorials from, but not
restricted to the following fields. Everything KDE-related will be
considered.
- KDE and Qt programming tricks
- DCOP, KParts, KOffice, multimedia etc. development
- programming tools, patterns
- programming patterns and development strategies
- project management issues
- internationalization
- documentation
- usability, accessibility, interoperability
Talks will be scheduled for 45 minutes talk and 15 minutes Q&A. In
some cases, it may be possible to occupy two slots for a total talk
time of 90 minutes or offer short presentations of 15 minutes
each. Please note the estimated talking time in your application.
Finally, BoF sessions can be announced in advance or planned on the
spot. A limited number of group rooms will be available for BoFs.
Submission Guidelines
Those proposing to present papers should submit an abstract including
the name and e-mail address of the author or authors to
[email protected]. The conference language is English. The
abstracts will be reviewed by the program committee based on content,
presentation and suitability for the event. By submitting an abstract
you give permission to publish it on the conference web site.
Location
The KDE Developers' Conference will take place at the Zamek ("Castle")
in Nove Hrady in the southern part of the Czech Republic in Central
Europe. Facilities are hosted and sponsored by the Institute of
Physical Biology of the University of South Bohemia. Nove Hrady cannot
easily be reached by public transportations, but a shuttle service
will be provided from Prague-Ruzyne airport and Prague Central
Station.
Speaker Incentives and Financial Compensation
The KDE Developers' Conference is run by KDE e.V., the Academic and
University Center Nove Hrady and the Polytechnic University of Upper
Austria in Hagenberg. KDE e.V. is a non-profit organization of
volunteering professionals and enthusiasts of free and open-source
software.
We only have a limited budget for this conference, and cannot
generally pay travel expenses or any other reimbursement or
gratification to speakers. We can provide accommodation and boarding
at a very low price (expect about 15-20 Euros per day for full board
and lodging, but don't expect luxury accommodation), and the shuttle
service from and to Prague will be free of charge.
KDE e.V. is soliciting donations from companies and individuals
towards this conference. These donations will be used both for running
the conference and for bursaries for delegates from other continents
and/or without income. Delegates with an accepted paper will be
prioritized in the distribution of these bursaries.
Please note that even if we can grant you a bursary, you will still be
expected to pay a part of trip yourself, as well as your boarding and
lodging.
Important Dates
Please submit your contributions no later than the indicated dates:
Abstract submission deadline:
May 31, 2003
Acceptance notification:
June 16, 2003
Final papers due:
July 16, 2003
all 23:59 UTC
For the Program Committee
Matthias Kalle Dalheimer
President, KDE e.V.
Comments
Thanks Derek!... uh,... oh,... hey! This is not the CVS digest, is it!? ;-) Where's Derek today? Is he alright?
Anyway, good luck all of you who will attend to the Nove Hrady Conference
How about if a Perl or PHP "free geek" writes dynamic webpage that generates the content of the digest for Derek?
Then you will have digest whenever you reload it!
It has only to access the cvs databese and the kde C++ "free geeks" who decide that a given commit of their work is important to the project just just paste a line like this at the end of the commit message:
---
for DerekScript
[bug #34535] [optimize] [in-reply-to-commit #38945]
---
Beleive me it is possible.
"free geek" is used for a "open source community contributor". I think Derek is definitely a HTML "free geek", but may be also he is a Perl or PHP one, or also may be he already did it.
Why do you say that Derek is an «HTML geek»?
Everyone is capable of writting an HTML page using Mozilla Composer :p
And hopefully, Quanta will also have an WYSIWYG mode!! Terrific :D
Well, I already posted my suggested development strategy to the KDE Development list and basically, nobody seemed to like it.
:-(
What is it? What have you suggested?
I also would suggest something but if there was a kgod to hear it.
I guess he means the bigheaded http://lists.kde.org/?l=kde-devel&m=105302958112948&w=2: "I am a IT professional [..] I think that a mature IT professional should get some respect from self taught hackers half his age." Many of his postings show this attitude like: I'm professional, you're young/hacker, KDE is a mess. I'm here to ransom you.
Thanks for the link, I obviously missed it before. Now after reading it I know as much as before though. (Question to James Richard Tyrer:) What is that whole fuzz intended to be about?
Sorry, but that is the wrong link.
My comments on a "Demming style" development strategy were posted some time ago.
--
JRT
http://lists.kde.org/?l=kde-devel&m=103855731706945&w=2
Did you ever consider that KDE 3.1.0 compiled for the great majority without problems and your compilation problem is not representative? In my opinion KDE 3.1.2 and what 3.1.x will follow show that developers care about bugs and a switch unstable->branch and stable->HEAD wouldn't change anything.
And thanks for delivering another example of your attitude: "I also wanted to make a note here so that everyone that reads this will know: I am a professional programmer retired on disability. I studied Electrical Engineering & Computer Science in college. There is much that I do not know about the KDE project. But I know a lot more about computer programing than some of the self taught hackers that have been telling me that I don't know anything (yes that is an arogrant remark).
I don't appreciate it and you only make fools of yourself doing it."
And you still wonder that you don't get appreciation/respect back...
> Did you ever consider that KDE 3.1.0 compiled for the great majority without
> problems and your compilation problem is not representative?
No, because there were problems with it.
Why did I, and others, notice that there were problems with it?
Well in my case it was because I had been building 3.0+ from CVS for some time without any problem but when I updated with the release tag that it didn't work.
I'm sorry that I don't remember the exact problems but they were fixed.
> In my opinion KDE 3.1.2 and what 3.1.x will follow show that developers care
> about bugs and a switch unstable->branch and stable->HEAD wouldn't change
> anything.
Things have improved, but there is still some sentiment that some developers care more about new features than fixing bugs.
What I said was more than your terse response indicates, but yes it would change things. Bugs would first be fixed in the current release and new features would have to accommodate bug fixes rather than bug fixes having to accommodate new features.
You may disagree with my ideas, that is fine. But your remarks actually show that you didn't take the time to understand my ideas before rejecting them out of hand.
> And thanks for delivering another example of your attitude
And I see that you didn't get the point of what I said was a deliberately arrogant remark either.
I did have a point there. I thought that it was possible that some of the 'arrogant developers' had made remarks because they thought that I was some newbie that had just wandered in. I was wrong, 'arrogant developers' make these remarks to everyone that isn't part of the hacker culture.
You should be aware of the fact that this kind of discussion style is quickly bringing yourself on many peoples' ignore list. Please separate you ideas and suggestions from your personal issues and avoid using the latter. It's a waste of time discussing about personal issues while the same time could be used to clarify ideas and suggestions instead which would actually help everyone.
> It's a waste of time discussing about personal issues while the same time could
> be used to clarify ideas and suggestions instead which would actually help
> everyone.
Thank you: I agree 100%. So, I will stop responding to personal comments.
I hope that you can see, as I do, that the problem does not lie with me. I would like to discuss ideas but those that don't respond with personal attacks.
Why do you think that this is what happens? It is certainly not what other engineers would do! Are they threatened by someone that has different ideas? Is this just part of the 'arrogant developer' syndrome?
I also had a suggestion: regular Knoppix based Live CD releases containing KDE CVS Head snapshots for danger-free preview and encouraging press coverage of all those "technology previews", teasing everyone who's saying KDE's not progressing due to missing development releases. Now I just need people picking that up and work on it (no kgod needed).
Why don't you create them? Telling what has to be done doesn't get the work done (with greetings to James 'I do not feel that I am currently able to write code' Richard Tyrer).
I'm not telling what has to be done but suggesting what would be nice to have considering "everyone"'s request to KDE to release develoment releases aka snapshots like Gnome does but KDE remove long time ago (and rightly so imo). Sure, if nobody else picks up my suggestions I'm surely going to end up doing it myself.
What about ftp://ftp.kde.org/pub/kde/snapshots ?
Or are you talking about compiled snapshots? Then feel free to talk to the distributors or volunteer to do it yourself. To cite http://www.kde.org/download/packagepolicy.php:
"When will you offer packages for my favorite distribution?
We will ship packages for your favorite distribution when (and only when) your distribution or a dedicated user builds the packages and submits them to us for redistribution. The KDE Project itself does not make any binary packages."
I know that already, thanks you. =) What I was talking about was regularly creating a live CD containing a recent KDE snapshot from CVS Head to showcase it as "technology preview" so people can easily check out to where KDE is heading. Doing that as live CD has the advantages that it's easy to pick up, easy to review, easy to include a lot of warning signs "not intended for productive use", easy to promote the current development etc. etc. while avoiding the issues usually introduced with "official development snapshot releases" (ie. users installing it and then misleadingly thinking that it can be used for productive use creating a lot of questions and bug reports etc). And as I said if nobody intends to pick that up I'll surely giving it a try myself sometime. =)
Sorry, but this conference is only for development strategies with developers who are committed to do them...
Did I miss something here?
A 'development strategy' is NOT writing code.
It is a methodology that is used in wrinting code.
And just exactly why would a methodology based on Deming's ideas of quality assurance be unsuitable for this conference?
To me it appears to be a trade off: more features vs. higher quality.
Commercial software has the exact same issue and they usually make the same (WRONG) choice: more features.
It's a waste of everyone's time to do more than to submit a feature or change request to bugs.kde.org, UNLESS there is a developer who is at least interested in implementing it. It just annoys everyone, as you can see.
The scarce resource is not ideas or concepts, it is developer time.
> It just annoys everyone, as you can see.
Not really.. A lot of developers tend to look at bugs by number of votes. So, if you can get people to vote for your bugs, it can do wonders.
Sure, voting is a good thing. But please dont make off-topic advertisements for your favorite bug, because when everybody does this dot.kde.org wont be much fun to read...
As an 18 year old who has been teaching himself C++ since he was 16 (specifically so that he could help with KDE development), I have to say that I did find your message rather rude and arrrogant, while at the same time you were accusing other people of being rude.
Yes, the way KDE is developed certainly could be improved I'm sure. However you seem not to totally understand the processes by which KDE is developed, and the way that KDE is developed is not going to suddenly change overnight because some relative outsider (e.g. somebody that doesn't contribute code) says that another way is "better".
I suppose that this will start a major flame war, but:
1. People have been rude to me. They have dismissed what I have said with a one sentence comment that indicated that they didn't really know what I was talking about but appeared to indicate that I didn't know anything.
2. You probably don't understand it, but you do represent my remark. You think that because you have taught yourself C++ that you now know programing. So, you probably know C++ better than I do, but do you think that 5 years persuing a degree in EE & CS taught me nothing more than you know?
3. No, I do not understand the way KDE is developed, but I don't mean that the same way that you do. Perhaps you could explain it to me.
4. I should make it clear that ideas I have suggested are not my ideas. They are from what I have learned in college, and over the years since I attended UCSB in the '70s.
I'm not interested in flaming, only getting to the facts.
1. I'm sorry that you feel that, but I do not consider people to have been rude to you, certainly not intentionally.
2. Rubbish. Totally, absolutely, and fundamentally wrong. There's a vast amount about C++ and programming I don't know. I certainly don't consider that I "know about programming". I strive to improve where I can. I do not know of any fellow contributors _All_ of my fellow contributors are similarly eager to learn in my experience.
On the other hand, it seems to me that because you spent 5 years doing a degree in EE & CS you automatically feel qualified to try and force your opinions onto all about the way that KDE should be developed.
3. Describing it in words would be rather hard. The only way you can understand is by obvserving the way that the project runs itself for several release cycles, maybe contribute a bit of code.
"I do not know of any fellow contributors _All_ of my fellow contributors are similarly eager to learn in my experience."
should read
"I do not know of any fellow contributors who are not similarly eager to learn."
1/2/4. If you want to impress people with your programming skills, produce code (documentation etc) that impresses them. Or help people when they ask for help.
But when you send unsolicited change requests/re-design proposals/development strategies, then don't complain when people do not agree with you or don't want to do them for various reasons.
3. Actually quite easy: who codes decides. Maintainers are responsible for their work. If there is something that affects more than a single sub-project or for other significant decisions, decisions are made by consensus. Or, in minor cases, by talking to one of the respected long-time developers.
> 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.
Maybe you should learn from Eric Laffoon. Look what he achieved with Quanta Plus by being behind many of the design decisions and sponsoring.
> 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.
>>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...
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?
> 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.
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.
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.
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
Yes, John.
But, that *is* what engineers do. It is what they are trained to do.
Find the fault.
--
JRT
> 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.
> 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.
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.
You're wrongly mixing up relation and functionality of lists.kde.org<->mailman and pipermail.
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. =)
Contact [email protected]
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 ...
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 ...'.
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?"
> 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 ....
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.
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