Le Wed, Nov 07, 2001 at 01:28:34AM +1000, Anthony Towns �crivait: > Which indicates nothing more than that you didn't understand what I said.
Granted. > > Of course I have : > > - unofficial means "not referenced in any debian documentation" > > If that's exactly what it means, then in the interests of clarity, > you'd've been better off saying "documented" instead of "official". When things are documented in official Debian documents, I consider them as "official". (we could argue about which documents are official but I hope nobody will go in this direction...) Call it documented if you want, the result is the same. > > - official means "documented" and therefore #debian-devel would follow the > > policy that Debian has decided for it > > Again, that's a tautology. The "policy" that Debian's "decided" for it is > "whatever the channel opeators say, goes". I don't think so. Overfiend told that he would apply whatever policy we come up with. According to that statement, it's up to Debian to clarify how #debian-devel should be managed. And I accept this because the population of #debian-devel is a representative subset of Debian which accept the decisions of Debian as a whole. > Which is all very well, but you need to *argue* that point, damn it, > not blather on about "officialness", and mention it in brackets as though > it were some sort of self-evident corollary. Well, I'll try to show you that my argument should already be well known even if not directly expressed as you seem to request it. I'll try a summary especially for you. :-) > Excepting the fact that it's not documented publically anywhere, and > is a hidden (+s) channel, so that people don't know about it in the > first place. Except when they do a /whois buxy for example while i'm in another debian related channel. Except when they read about it in a public list like here. Except when they learn the existence of that channel because a friend spoke about it. Except when they have been invited by people already on #debian-devel. > > by letting future maintainers join (and > > lurk), we'll let them learn faster how Debian works. > > Congratulations! Some actual justification for what you want to happen! Correction: it already happened so several times. I'm asking that we continue in this direction. Unfortunately the opinion on this precise point seems to be controversial. Wichert and Overfiend disagree, and other do also. This needs to be decided. > This isn't particularly true, though: for a start, we already provide > debian-policy, the developers-reference, several example packages and > helper tools, and the new-maintainer process; they're the "official" > guides to learning how Debian works, and they're available via the > traditional Debian avenues: the package system and email. That's an official part, there's also the "concrete" part. Lurking on #debian-devel, you can rapidly learn things about debian-www just by reading what Joy (Josip Rodin) regularly writes. You can see the work done by Joey (Martin Schulze), you may have news about the development of katie by elmo (James Troup). You may also have considerations about testing from you. You may learn about porting issues because a porter is discussing a bug regarding the recompilation of a package on ia64. That's the kind of things you learn, that get you in touch with Debian's life, that can motivate one to work for Debian. That can help someone decide to help on a precise point. > Debian seems pretty clear: don't have to worry about "Debian SuX" trolls, > don't have to worry about answering user questions, don't have to worry > that someone's watching your every word about to jump all over it. Sure, I also want it to be effective. But we don't need to restrict to official debian developer just because of this. I just want it to be "controlled" by signal/noise consideration. That's enough for that. > And as far as that's concerned there's another problem with making irc > at all official, which has been alluded to elsewhere in this thread. IRC I already replied. IRC would be an alternate non mandatory communication channel. I don't see how it can be a problem. > I'm sure you have. Unfortunately you haven't told us what those principles > actually *are*, or why you think other people should hold them, or why > what you want to happen follows from them. Ok, I'll try to summarize for you. PRINCIPLES : 1. Debian should be open. 2. Debian should try to avoid frustrating people outside of Debian who are potential future maintainers or future contributors. 3. Developers should be able to get things done with a minimum of fuss. References (in the GR) : - For the first principle I said : | * Debian's philosophy concerning the development has always been to open | the communication channels. There's a mismatch here. - For the second principle I said : | * Debian can't treat valuable contributors like it's done actually on | IRC. Kicking a person who naturally has its place within the | developer's community (because of his interest and his work) is not | reasonable. | (Personal note: this kind of behavior gives Debian its bad image | of a closed community preaching openness) - For the third principle I said : | - the "netiquette" (RFC 1855, section 4.1.2) applies, channels' | subjects should be respected (I may add "trolls are not welcome" if you wish) All my principles are respected. They may have not been explicitely given, but they are not really hard to deduce. When we transpose the principles to the concrete case of #debian-devel. The third principle has always been more or less applied to it. The first was only partially respected since we accepted people outside of Debian but not always. The second principle has been broken by Overfiend when he kicked chris38 (Christian Bayle) who is not a developer. chris38 hadn't polluted the channel at all. He was following just because he's very interested in Debian. He's even helping Lo-lan-do (Roland Mas) in the packaging of sourceforge. I always took the 3 principles as more or less granted on #debian-devel. But the recent events proved me wrong. So, there has been a discussion why Overfiend did this. He explained that he just applied an old policy. Now, people can't even agree on that old policy. Overfiend then explained that he would apply whatever policy we come up with. Now, my GR is about solving that. That's the way I followed in my reflexion. It may not be the only solution, it's a solution that I'm proposing. I hope you don't need more details about how/why my GR is solving that. This part has been explained enough in this tread I think. You ask me why I think the principles above are important to follow. I'll tell you, because it is the first principle which brought Debian where it is now. We have an open BTS, we have open lists ... For the second principle, I believe it is important to respect future maintainers and contributors and to try to not disgust them with being rude (and i'm not speaking about technical skills here ... i'm speaking about "social life") because we need them to achieve our goal and because they are Debian's future. And the third principle is important because we can't afford to sacrify our effectiveness for whatever reason. Cheers, -- Rapha�l Hertzog -+- http://strasbourg.linuxfr.org/~raphael/ Le bouche � oreille du Net : http://www.beetell.com Naviguer sans se fatiguer � chercher : http://www.deenoo.com Formation Linux et logiciel libre : http://www.logidee.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
