On Tue, April 25, 2006 6:45 am, Ted Husted said: > I should mention that proposals for change are best sent to [EMAIL PROTECTED] > This > list is meant for people who want help using a product. Changes to the > project are best discussed on [EMAIL PROTECTED] We should get back on task as > to > the role of each list, and :) stop annoying people who just want to > know how to use the taglibs :)
Yes, I considered doing that... but as my proposal was specifically *for* the community, I felt it important to put the most number of eyeballs on it as possible. You know, perhaps we need *three* mailing lists... one for devs, one for users who just want questions answered, and one for the "community", those that want to be involved in shaping things but that aren't committers. :) > Back at Jakarta, we used to have committer votes on public lists, and > I saw a lot of those go very wrong. People would use them as an excuse > to talk about something else. It's hard to have a candid discussion > about a *person* on a public list. As it turns out, the Apache HTTPD > team has never had discussions about people on a public list. I think > that is a much better way to go. We announce the tallies for the > committer votes that succeed, but we don't embarrass people by > announcing votes and discussions that fail. I certainly see the point your making, I happen to agree with it. Perhaps it should work more like a senate confirmation hearing in the sense that before you begin to discuss someone you ask them if they want to be considered, and then have the discussions in public? (I think Niall more or less suggests the same thing in this thread). If a person accepts a nomination, they then accept the public debate, and any embarassment that might result. Just a thought. > If you want to "force" a vote by the PMC, why not just bring one up on > [EMAIL PROTECTED] But, please, check with the nominee first, to be sure he or > she > wishes to be discussed on a public list in this way. I didn't frankly know that was an option... has that ever happened before? If there is some unofficial policy in this regard, I'd be happy to know about it... as long as there is some unwritten rule that the PMC will vote on a nominee made by someone not on the PMC, then the underlying spirit of my proposal is already in place... I think it's always better to codify these kinds of things, but I can live with an unwritten rule :) I'd like to know that it has been exercised in the past though. > From an ASF perspective, the "community" is not everyone who > subscribes to the mailing list and downloads the product. The > community is the set of individuals who contribute to the project, > both by making helpful posts to the mailing list *and* by contributing > useful code and documentation. Downloads don't make the product > possible. Contributions make the product possible. Our customers are > the contributors, who pay for the product with posts and patches. I guess this is one way that I've never quite "got it", as Craig says :) I view the community as being larger than just those contributing. While I have no problem affording something "more" to those that contribute, I think those simply using the product have a stake in it. They can of course choose to ignore that stake, but they can exercise interest if they wish. For me, the community would be "anyone who has an active interest in how the project develops". Those that contribute in some way deserve a louder voice and a bigger say in things, but I don't think contributing is the only criteria for being in the community. But that is my interpretation, I realize it doesn't jive with the ASF interpretation :) > Over the years, I think there have been exactly two committer > nominations here that failed, and both times the failed nominees had > not submitted a single patch. Question: does submitting a patch have to mean having the patch accepted? At first glance, the obvious answer is yes, but I'm not so sure it's really the obvious answer... if someone has submitted a number of patches that were not committed for reasons other than purely technical (i.e., the patch will break X), should those patches be considered? >> But, at the end of the >> day, who is invited to join is still decided by the PMC, as it is today. > > :) Well, yeah. We're the ones that have to live with the decision, > long after whoever "voted" on the nomiantion might have unsubscribed > and faded away. :) Yep :) > Who I would feel sorry for is all the people who might be nominated, > and then turned down, on a public list, without ever even asking to be > nominated or discussed in a public forum. This isn't about making > legislation or winning a popularity contest. We need people who *can > and do* create code or documentation and *collaborate* with other team > members, without a suit or "lead developer" pulling the strings. Yes, that's why I'm not completely against the private system in place now. I do agree with your point here. As I suggested earlier, the easy solution might be simply to ask a nominee if they want to be considered... if they do, they accept whatever might come out. At least then the reasons for a failed nomination are obvious to all, including the nominee, there is no opportunity for anyone to accuse the PMC of doing anything improper. I believe transparency is good, but I also think not embarassing people is good... accepting a nomination seems like a good compromise to me. > One blind spot right now might be the wiki. Some people have been > making some great contributions to the wiki, but because they don't go > into the repository, they don't seem like patches. But, we should > start considering wiki contributions to be as valuable as > contributions to the other documentation. I would agree with that, and not just because I've made a few contributions to the Wiki! :) > And thanks for this post, and all the other helpful posts you and so > many others make to the list. No problem... I derive a lot of enjoyment from helping people when I can. Thanks for considering :) Frank --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
