Re: Deficiencies in Debian
On Fri, 18 May 2007 22:09:56 -0700, Russ Allbery wrote: [training the next generation] I'm not following the Linux community closely; do you think there are points Debian could adopt or learn from? I try to summarize (hopefully correctly) your points: With Linux, I think it helps a lot that many of the people involved in kernel development are paid to do it and mentor others as part of their job. I do similar things for Debian, training other people in my group on how to build Debian packages and participate in the infrastructure, and hopefully over time that will bear fruit for Debian as well. - experienced people as mentors for newcomers Linux also has a good history of organized projects to help people get started, such as kernel janitors, and puts a lot of effort into collaboration infrastructure. - teamwork and collaboration, facilitated by the necessary infrastructure And one of the best things about the Linux model is that Linus regularly talks about how he wants things done and what leads him to take stuff or not take stuff in public on the lists, which leads others to do the same. And those are interactive discussions, not just writeups. I think people learn a lot from those discussions. - open discussions about future developments On Debian, the impression that I've gotten is that a lot of the real mentoring and discussion actually happens on IRC rather than on the lists. I don't know how effective that is. I don't know either; probably there's a lot to grab by just following some channels but OTOH the S/N ration is sometimes not really helpful and IRC doesn't seem to be a dedicated mentoring approach at the moment. Regarding your other points I think * there is a trend towards more teamwork and there is infrastructure available for it; * mentoring is happening by chance (in the teams, by some long-time sponsors, maybe by some AMs) but not in a planned way; * maybe some discussions are initially not led in public (but I'm not sure about that one). Hm, maybe that sounds naïve, but what about thinking about a way to adopt strategies of mentoring, development, fine graining roles (job descriptions, mutual agreements, appraisalevaluation, ...) , etc. to F/LOSS in general and Debian in particular? The main obstacle that I see is that that stuff takes a lot of time. I spend probably 5% of my work time on the coordination, record-keeping, and reporting parts of that sort of activity, which in a full-time job is quite reasonable. But it's not really a percentage; it's a quantity of time that those activities take. And I couldn't take a similar two hour per week cut out of my Debian volunteer work without a much greater impact on how much stuff I could get done. Sure, mentoring/training/staff development takes time but as you point out at the beginning it probably bear[s] fruit for Debian. Maybe Debian would be better off in the long run if some of the experienced DDs decided to drop one package or resign from one infrastructure task and to use the saved time for taking an apprentice. I don't know if there have been any organized mentoring/training programmes in Debian in the past; the only one I know at the moment is organized by the Debian Women project [0] but TTBOMK it's not very active. -- IMO it's a good idea anyway! Cheers, gregor [0] http://women.debian.org/mentoring/ -- .''`. http://info.comodo.priv.at/ | gpg key ID: 0x00F3CFE4 : :' : debian: the universal operating system - http://www.debian.org/ `. `' member of https://www.vibe.at/ | how to reply: http://got.to/quote/ `-NP: Rolling Stones: She's A Rainbow (45 version)/She's a Rainbow - 2 signature.asc Description: Digital signature
Re: Deficiencies in Debian
gregor herrmann [EMAIL PROTECTED] writes: On Fri, 18 May 2007 22:09:56 -0700, Russ Allbery wrote: And one of the best things about the Linux model is that Linus regularly talks about how he wants things done and what leads him to take stuff or not take stuff in public on the lists, which leads others to do the same. And those are interactive discussions, not just writeups. I think people learn a lot from those discussions. - open discussions about future developments Here, it wasn't as much future developments that I was thinking of as more basic issues, like style and the thought processes behind why the kernel is structured the way it is. Linus does a great job of explaining his sense of taste, which is sort of a meta-level above future development. I think the Debian Policy discussions, if we can kick up the level of activity, could partly serve a similar role within Debian. There are also some Debian developers (Steve Langasek and Manoj Srivastava come to mind) who regularly follow up to threads on debian-devel and explain both their aesthetic judgement and how they arrived at that conclusion. IMO, one of the most valuable skills for someone working in IT is to have a well-developed aesthetic sense of what a clean and supportable system looks like. Most of the day-to-day decisions that I make are based on a sense of aesthetics more than specific technical criteria. That's the form that my subconscious gestalt of systems takes. My experience is that once one has developed that sense of aesthetics and learned to look closely at anything that feels ugly, it becomes surprisingly effective at pointing directly at the weak parts of any design. The main obstacle that I see is that that stuff takes a lot of time. I spend probably 5% of my work time on the coordination, record-keeping, and reporting parts of that sort of activity, which in a full-time job is quite reasonable. But it's not really a percentage; it's a quantity of time that those activities take. And I couldn't take a similar two hour per week cut out of my Debian volunteer work without a much greater impact on how much stuff I could get done. Sure, mentoring/training/staff development takes time but as you point out at the beginning it probably bear[s] fruit for Debian. Maybe Debian would be better off in the long run if some of the experienced DDs decided to drop one package or resign from one infrastructure task and to use the saved time for taking an apprentice. Probably true. Although two hours a week is way more than just one typical package. That's probably the total time I spend on lintian, for example, or about five or ten regular packages where I'm just packaging upstream releases. (Not that I'm an experienced DD; I'm still fairly new.) -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Deficiencies in Debian
Raphael Hertzog [EMAIL PROTECTED] writes: On Thu, 10 May 2007, Russ Allbery wrote: In a workplace environment, this sort of thing is often addressed by putting mentoring and staff development on the performance goals of senior staff and freeing up time that they're supposed to dedicate to training and documentation. Debian doesn't have that luxury, and I don't know what, if anything, we can effectively do at a project organization level to accomplish a similar goal. What about doing something like that ? http://wiki.debian.org/Teams I've documented the Alioth team and I'll probably continue doing something similar for some other teams that I know quite well. This is very recent, I started it this week and I'd like to have some feedback on the structure of the template page (see http://wiki.debian.org/TeamTemplate). Are the important information missing? Are some information useless? This looks good to me as a way to gather information. We've done exercises like this internally in my group at Stanford and they were useful in helping people see what the different parts of the group do. It doesn't, in and of itself, help with mentoring and training, but it can serve as a starting point for identifying places where it's needed and can be a start on internal documentation for how tasks are performed. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Deficiencies in Debian
On Thu, May 10, 2007 at 11:14:32PM +0200, Raphael Hertzog wrote: I've documented the Alioth team and I'll probably continue doing something similar for some other teams that I know quite well. This is very recent, I started it this week and I'd like to have some feedback on the structure of the template page (see http://wiki.debian.org/TeamTemplate). Are the important information missing? Are some information useless? I liked the idea and I took the freedom of making some minor changes: - adding a level 1 heading for the team name - adding a field for referencing an alioth project (if any) Thanks for the idea, Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science ... now what? [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time signature.asc Description: Digital signature
Re: Deficiencies in Debian
On Thu, May 10, 2007 at 01:42:37PM -0700, Russ Allbery wrote: gregor herrmann [EMAIL PROTECTED] writes: [cc and reply-to/m-f-t [EMAIL PROTECTED] On Thu, 10 May 2007 12:32:26 -0700, Russ Allbery wrote: There are other things that *are* signs of fundamental deficiencies in the project, Would you mind to elaborate on this point, I'm really interested in your opinion. The biggest problem with most open source / free software projects that I've been involved in is the bottleneck around evaluating and accepting infrastructural improvements. It's a very hard problem and I'm not saying that Debian is necessarily much worse off than many other projects, but we also have this problem in spades. You mean like the when the problems i now have are a direct result of me trying to discuss improvements over the way the kernel and d-i are related, and the immobilism/rejection/whatever of the core d-i team over it, which led them to try to undermine my position as lead kernel team member to further their position ? In a workplace environment, this sort of thing is often addressed by putting mentoring and staff development on the performance goals of senior staff and freeing up time that they're supposed to dedicate to training and documentation. Debian doesn't have that luxury, and I don't know what, if anything, we can effectively do at a project organization level to accomplish a similar goal. That is the problem here indeed. Debian has no workplace culture, and those who managed to attain power position, have not done so because they are good in mentoring/staff situation, but because they where able to devote huge amount of time on specific topics. Not necessarily, as experience showed, because they have technical skills, but simply because they where able to allot time. People are often able to use much time, because they severly lack social skills, and pass many hours and nights on their computer, in the true nerdy tradition, and in general have as a consequence a bad ability to relate to other, not even speaking of their needed human-ressource handling and leadership positions. On top of that, those people often have or develop over time, a strong opinion of theirself, and are thus inflexible, unable to put themselves in question, or recognize they may be wrong, and given debian's model, they are sole dictators of their own area of expertise, and can do as they please, how badly this is for debian, or how bastardly they behave toward their fellow DDs. On top of that, we have seen the emergeance of a new set of people, who maybe evolved from the previous one, who were adept at manipulating the other DDs, dealing in half-truth, and outright manipulation, and the worse of this, is that they probably are not concious of what they are doing. And then the money factor enters the picture, and with it the power actually hold by those who are able to make other believe they represent debian, and you have the receipe for disaster. Saddened, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Deficiencies in Debian
Hi, On Thu, 10 May 2007, gregor herrmann wrote: * I'd move the Task description to the top - IMO what's it all about/what's the objective? has the top-most priority. Not really IMO. The very short description on the Teams page is enough to understand what the team is about. This paragraph here is just a somewhat more detailed reminder. * IMO the next step would be to define and publish similar pages not only for special teams but for all roles (be they teams or individuals) in Debian. Sure. All roles should be teams anyway. :-) I've documented the Alioth team and I'll probably continue doing something similar for some other teams that I know quite well. I hope you do that for the Debian Perl Group so that I don't have to learn the wiki stuff ;-) Actually, I probably won't. Packaging teams are not my priority in this exercise. The real problems that we have are more in the teams that handle our infrastructure. I started it this week and I'd like to have some feedback on the structure of the template page (see http://wiki.debian.org/TeamTemplate). Are the important information missing? Are some information useless? I'm not sure if the Usual roles apply often to teams. I think this is one of the most important section in those pages. It documents who is the best point of contact for a specific task and let outsiders check if there's an opportunity for him. Of course, for packaging teams it might be less important. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Deficiencies in Debian
[ For people on debian-www, we're speaking of http://wiki.debian.org/Teams ] On Fri, 11 May 2007, Charles Plessy wrote: One problem I see with Usual roles with names in, is that it is another page to keep in sync with http://www.debian.org/intro/organization and I know that there's some duplication. But until this page is easy to edit by the various teams themselves, this page will regularly have outdated content. It's quite possible that we should shrink /intro/organization to list only constitutional roles and that the wiki should be the reference for the rest where each team can manage its own page. BTW, the list for Alioth administration is wrong in the website. Wichert Akkerman has left and we recruited Stephen Gran. http://alioth.debian.org/projects/theparticularteam, with all the potential problems, disagreements and frustrations that it means, and also the risk of having just another outdated page which suggest that a team is full of members while it has shrunk compared to the past year(s). The wiki has less chance of being outdated than the website. So I'd rather have this particular content there and have the website link there. I know that the wiki can't be translated currently but this is content for contributors and they have to contribute in english anyway. Anyway, this is for later, once the wiki is a somewhat complete replacement for that page. Right now, it's far from that. Maybe describing the roles to fit in without names would help to promote redundancy, which in the context of organisations with a high turnover is one of the ways to secure the future? No. I want something that matches reality of day-to-day work. Not yet another theoretical description of how we should probably do things. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Deficiencies in Debian
Hi, On Friday 11 May 2007 08:46, Raphael Hertzog wrote: BTW, the list for Alioth administration is wrong in the website. Wichert Akkerman has left and we recruited Stephen Gran. fixed in CVS. regards, Holger pgpmg0xcK7P7D.pgp Description: PGP signature
Re: Deficiencies in Debian
On Fri, May 11, 2007 at 08:32:23AM +0200, Sven Luther wrote: You mean like the when the problems i now have are a direct result of me THIS THREAD IS NOT ABOUT YOU PLEASE. PLEASE LEAVE. -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Deficiencies in Debian
On Fri, May 11, 2007 at 07:56:09PM +1000, Hamish Moffatt wrote: On Fri, May 11, 2007 at 08:32:23AM +0200, Sven Luther wrote: You mean like the when the problems i now have are a direct result of me THIS THREAD IS NOT ABOUT YOU PLEASE. PLEASE LEAVE. Then please comment on the second part of my post, and stop making it an attack on me instead. You are as much responsible of what you accuse me of, than me, if not more so. Saddened, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Deficiencies in Debian
On Fri, May 11, 2007, Sven Luther wrote: On Fri, May 11, 2007 at 07:56:09PM +1000, Hamish Moffatt wrote: THIS THREAD IS NOT ABOUT YOU PLEASE. PLEASE LEAVE. Then please comment on the second part of my post, and stop making it an attack on me instead. You are as much responsible of what you accuse me of, than me, if not more so. Please, Sven. There is already one thread about you in -vote where you are already copiously posting and that people are acutely following. I therefore suggest restricting your interventions to that thread. Having all your posts in the same thread makes it easier for the people who wish to help you to see your arguments, for instance by tagging the whole thread as important. If you post at too many different places, these people who wish to help you may miss valuable information. Thanks in advance, -- Sam. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Deficiencies in Debian
On Fri, May 11, 2007 at 04:13:48PM +0200, Sam Hocevar wrote: On Fri, May 11, 2007, Sven Luther wrote: On Fri, May 11, 2007 at 07:56:09PM +1000, Hamish Moffatt wrote: THIS THREAD IS NOT ABOUT YOU PLEASE. PLEASE LEAVE. Then please comment on the second part of my post, and stop making it an attack on me instead. You are as much responsible of what you accuse me of, than me, if not more so. Please, Sven. There is already one thread about you in -vote where you are already copiously posting and that people are acutely following. I therefore suggest restricting your interventions to that thread. Sam, please tell me, what in the second part of that post Hamish is refering too, is offtopic here ? I agree i should have maybe not posted the first bit of it, but the second part of it is fully on-topic here, no ? Having all your posts in the same thread makes it easier for the people who wish to help you to see your arguments, for instance by tagging the whole thread as important. If you post at too many different places, these people who wish to help you may miss valuable information. err, 2-3 are too many different places ? i guess you know to count only as 1-many then :) Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Deficiencies in Debian
Sam Hocevar [EMAIL PROTECTED] wrote: Please, Sven. There is already one thread about you in -vote where you are already copiously posting and that people are acutely following. I therefore suggest restricting your interventions to that thread. And a third one on debian-powerpc. Having all your posts in the same thread makes it easier for the people who wish to help you to see your arguments, for instance by tagging the whole thread as important. If you post at too many different places, these people who wish to help you may miss valuable information. ITYM it's easier to kill one thread than 3 ? JB. -- Julien BLACHE - Debian GNU/Linux Developer - [EMAIL PROTECTED] Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Deficiencies in Debian
On Fri, May 11, 2007, Sven Luther wrote: Please, Sven. There is already one thread about you in -vote where you are already copiously posting and that people are acutely following. I therefore suggest restricting your interventions to that thread. Sam, please tell me, what in the second part of that post Hamish is refering too, is offtopic here ? I agree i should have maybe not posted the first bit of it, but the second part of it is fully on-topic here, no ? I have not said you were off-topic. There are millions of different places where you would be on-topic. What I say is that it's better to be on-topic at one single strategic place, and what better place than our incredibly awesome Gay Nigger Association of America thread? Kindest regards, -- Sam. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Deficiencies in Debian
On Fri, May 11, 2007 at 05:17:01PM +0200, Sam Hocevar wrote: On Fri, May 11, 2007, Sven Luther wrote: Please, Sven. There is already one thread about you in -vote where you are already copiously posting and that people are acutely following. I therefore suggest restricting your interventions to that thread. Sam, please tell me, what in the second part of that post Hamish is refering too, is offtopic here ? I agree i should have maybe not posted the first bit of it, but the second part of it is fully on-topic here, no ? I have not said you were off-topic. There are millions of different places where you would be on-topic. What I say is that it's better to be on-topic at one single strategic place, and what better place than our incredibly awesome Gay Nigger Association of America thread? Possibly, but gregor and russ chose to move this subthread here, and i was recomended not to speak about myself. The second part of my mail i perfectly ontopic to russels original mail, and as thus belongs in the same thread as it, don't you think ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Deficiencies in Debian
On Fri, 11 May 2007 08:33:01 +0200, Raphael Hertzog wrote: I've documented the Alioth team and I'll probably continue doing something similar for some other teams that I know quite well. I hope you do that for the Debian Perl Group so that I don't have to learn the wiki stuff ;-) Actually, I probably won't. Packaging teams are not my priority in this exercise. The real problems that we have are more in the teams that handle our infrastructure. Fair enough; I've made my first attempts in wiki editing: http://wiki.debian.org/Teams/DebianPerlGroup Cheers, gregor -- .''`. http://info.comodo.priv.at/ | gpg key ID: 0x00F3CFE4 : :' : debian: the universal operating system - http://www.debian.org/ `. `' member of https://www.vibe.at/ | how to reply: http://got.to/quote/ `-NP: Reinhard Mey: Was in der Zeitung steht signature.asc Description: Digital signature
Deficiencies in Debian (was: A question to the Debian community ...)
[cc and reply-to/m-f-t [EMAIL PROTECTED] On Thu, 10 May 2007 12:32:26 -0700, Russ Allbery wrote: There are other things that *are* signs of fundamental deficiencies in the project, Would you mind to elaborate on this point, I'm really interested in your opinion. Cheers, gregor -- .''`. http://info.comodo.priv.at/ | gpg key ID: 0x00F3CFE4 : :' : debian: the universal operating system - http://www.debian.org/ `. `' member of https://www.vibe.at/ | how to reply: http://got.to/quote/ `-NP: Miles Davis: Don't Stop Me Now signature.asc Description: Digital signature
Re: Deficiencies in Debian
gregor herrmann [EMAIL PROTECTED] writes: [cc and reply-to/m-f-t [EMAIL PROTECTED] On Thu, 10 May 2007 12:32:26 -0700, Russ Allbery wrote: There are other things that *are* signs of fundamental deficiencies in the project, Would you mind to elaborate on this point, I'm really interested in your opinion. The biggest problem with most open source / free software projects that I've been involved in is the bottleneck around evaluating and accepting infrastructural improvements. It's a very hard problem and I'm not saying that Debian is necessarily much worse off than many other projects, but we also have this problem in spades. The problem basically reduces to this: The core infrastructure is very important and therefore requires close monitoring and rigorous evaluation of what goes into it. It also can be subtle and complex and evaluating changes can be hard. There is always a core of people who understand the core infrastructure and feel confident in their ability to make changes, but due to the nature of dissemination of knowledge in a project, those people are also the best-positioned to make many other changes in a project and therefore are inevitably overloaded. And any changes single-track through the same people. As a result, there's usually little or no training of the next generation of people who can make infrastructure changes, less documentation than would be desirable of how things work, and few resources to evaluate changes and explain what would make them work. People who want to contribute to that central infrastructure get discouraged and frustrated and go away because no one has resources to show them what they might be doing wrong or, even if everything is great, even resources to simply commit and deploy their work. The people who do have the knowledge feel pulled in too many directions and tend to burn out. From the outside, the result looks like stagnation and arbitrary control of the center. From the inside, the result looks like stress, overwhelming workloads, impatient and frustrated people, and an impression that other people lack the care and caution required around the central infrastructure. I think this problem, in various different forms, is behind most of the major issues that are brought up in every DPL cycle and from time to time on -vote and -project. There isn't any silver bullet solution. If there was, we probably would have taken it already. Some projects do better with it than others. Linux does a relatively good job here. I'm heavily involved in some other projects that are doing much worse than Debian (INN, for instance, in large part because I'm currently putting more of my time into Debian). Oh, and by infrastructure, I mean generically whatever is at the core of the project. For Debian, this is things like the buildd network, ftp-master, Debian admin, central infrastructure packages, etc. For software projects, it's more often the core, trickiest code or the infrastructure on which everything else is built. For Usenet hierarchy administration, it's core policies around what newsgroups get created. It varies a lot. I think Debian does very well here in some areas and not as well in others, but Debian suffers from those structural flaws around finding a way to train the next group, relieve load and stress on core contributors, and still ensure that changes to the infrastructure are audited with the detail and care that is indicated. There have been improvements by fits and starts in the past few months, and I don't think any of this is news to anyone. In a workplace environment, this sort of thing is often addressed by putting mentoring and staff development on the performance goals of senior staff and freeing up time that they're supposed to dedicate to training and documentation. Debian doesn't have that luxury, and I don't know what, if anything, we can effectively do at a project organization level to accomplish a similar goal. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Deficiencies in Debian
On Thu, 10 May 2007, Russ Allbery wrote: In a workplace environment, this sort of thing is often addressed by putting mentoring and staff development on the performance goals of senior staff and freeing up time that they're supposed to dedicate to training and documentation. Debian doesn't have that luxury, and I don't know what, if anything, we can effectively do at a project organization level to accomplish a similar goal. What about doing something like that ? http://wiki.debian.org/Teams I've documented the Alioth team and I'll probably continue doing something similar for some other teams that I know quite well. This is very recent, I started it this week and I'd like to have some feedback on the structure of the template page (see http://wiki.debian.org/TeamTemplate). Are the important information missing? Are some information useless? Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Deficiencies in Debian
On Thu, 10 May 2007 13:42:37 -0700, Russ Allbery wrote: There are other things that *are* signs of fundamental deficiencies in the project, Would you mind to elaborate on this point, I'm really interested in your opinion. The biggest problem with most open source / free software projects that I've been involved in is the bottleneck around evaluating and accepting infrastructural improvements. Thanks alot for your detailed and at the same time succinct reply. Your analysis and conclusions look very logical to me; just a few questions/thoughts: There isn't any silver bullet solution. If there was, we probably would have taken it already. Some projects do better with it than others. Linux does a relatively good job here. I'm not following the Linux community closely; do you think there are points Debian could adopt or learn from? I think Debian does very well here in some areas and not as well in others, but Debian suffers from those structural flaws around finding a way to train the next group, relieve load and stress on core contributors, and still ensure that changes to the infrastructure are audited with the detail and care that is indicated. There have been improvements by fits and starts in the past few months, and I don't think any of this is news to anyone. Maybe working out what are the achievements and the deficiences in detail could provide a way for improvement. In a workplace environment, this sort of thing is often addressed by putting mentoring and staff development on the performance goals of senior staff and freeing up time that they're supposed to dedicate to training and documentation. Debian doesn't have that luxury, Hm, maybe that sounds naïve, but what about thinking about a way to adopt strategies of mentoring, development, fine graining roles (job descriptions, mutual agreements, appraisalevaluation, ...) , etc. to F/LOSS in general and Debian in particular? Cheers, gregor -- .''`. http://info.comodo.priv.at/ | gpg key ID: 0x00F3CFE4 : :' : debian: the universal operating system - http://www.debian.org/ `. `' member of https://www.vibe.at/ | how to reply: http://got.to/quote/ `-NP: Sinéad O'Connor: Emma's Song signature.asc Description: Digital signature
Re: Deficiencies in Debian
On Thu, 10 May 2007 23:14:32 +0200, Raphael Hertzog wrote: Debian doesn't have that luxury, and I don't know what, if anything, we can effectively do at a project organization level to accomplish a similar goal. What about doing something like that ? http://wiki.debian.org/Teams Looks like a good approach, thanks! Two quick thoughts: * I'd move the Task description to the top - IMO what's it all about/what's the objective? has the top-most priority. * IMO the next step would be to define and publish similar pages not only for special teams but for all roles (be they teams or individuals) in Debian. I've documented the Alioth team and I'll probably continue doing something similar for some other teams that I know quite well. I hope you do that for the Debian Perl Group so that I don't have to learn the wiki stuff ;-) I started it this week and I'd like to have some feedback on the structure of the template page (see http://wiki.debian.org/TeamTemplate). Are the important information missing? Are some information useless? I'm not sure if the Usual roles apply often to teams. Bonne soirée, gregor -- .''`. http://info.comodo.priv.at/ | gpg key ID: 0x00F3CFE4 : :' : debian: the universal operating system - http://www.debian.org/ `. `' member of https://www.vibe.at/ | how to reply: http://got.to/quote/ `-NP: Die Tontauben: flying signature.asc Description: Digital signature
Re: Deficiencies in Debian
Le Thu, May 10, 2007 at 11:59:40PM +0200, gregor herrmann a écrit : On Thu, 10 May 2007 23:14:32 +0200, Raphael Hertzog wrote: I started it this week and I'd like to have some feedback on the structure of the template page (see http://wiki.debian.org/TeamTemplate). Are the important information missing? Are some information useless? I'm not sure if the Usual roles apply often to teams. Hi all, One problem I see with Usual roles with names in, is that it is another page to keep in sync with http://www.debian.org/intro/organization and http://alioth.debian.org/projects/theparticularteam, with all the potential problems, disagreements and frustrations that it means, and also the risk of having just another outdated page which suggest that a team is full of members while it has shrunk compared to the past year(s). Maybe describing the roles to fit in without names would help to promote redundancy, which in the context of organisations with a high turnover is one of the ways to secure the future? Have a nice day, -- Charles Plessy http://charles.plessy.org Wako, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
