Re: Community Guidelines (was Code of Conduct)
On 7/6/07, J Aaron Farr [EMAIL PROTECTED] wrote: My concern is only when such documents become additional rules or bylaws and individuals start linking to them in their emails as justification for why someone has or has not done their duty. Maybe I'm just being picky and overly cautious. The intent was never to create additional rules or bylaws but to continue to collect, refine, and distill practices which already exist. As mentioned, most the material on the wiki can be merged into material that already exists, and the rest fills existing gaps in our documentation. * The Community Guidelines could be placed at apache.org under Get Involved, next to the Mailing List page. * The Example Project Guidelines could be placed at incubator.apache.org under Other Guides,. * The first part of the ASF Culture section could be merged with the Philosophy section of How the ASF Works, with the ASF Motto section being moved to it's own page, next to the Glossary of Apache-Related Terms http://apache.org/foundation/glossary.html. I'd like to make a few minor clarifications in response to the feedback in this thread, and then move toward integrating this material into the Apache and Incubator sites, as outlined. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Community Guidelines (was Code of Conduct)
Shane Curcuru [EMAIL PROTECTED] writes: I keep being surprised at the vehemence of feelings against writing down any sort of documentation that's non-technical... I didn't mean to suggest that I oppose any of the work that Ted, you or anyone else has done to document the fuzzy side of Apache. In fact, the opposite is true. I think having good How to contribute and This is how we do things and why documents is critical. My concern is only when such documents become additional rules or bylaws and individuals start linking to them in their emails as justification for why someone has or has not done their duty. Maybe I'm just being picky and overly cautious. -- J Aaron Farr jadetower.com[US] +1 724-964-4515 馮傑仁 cubiclemuses.com [HK] +852 8123-7905 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Community Guidelines (was Code of Conduct)
Ted Husted wrote: Any comments would be very welcome. Is that document supposed to be published outside the ASF? If so, I'd suggest to stress the fact (again) that discussions on a public mailing list are being archived and available for everyone to see. Every once in a while we still see these Could you remove my post from the archives-requests. Why is the use of author tags discouraged? I found these to be valuable information when trying to understand a piece of code, simply by recognizing the style of a certain author. Just my two cents. Bye, Thomas. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Community Guidelines (was Code of Conduct)
Thomas Vandahl wrote: Why is the use of author tags discouraged? I found these to be valuable information when trying to understand a piece of code, simply by recognizing the style of a certain author. 1. once committed, it isn't your code, it's the project's code. (Not from a copyright perspective, you still have that. But the copy in the ASF is now the project's to manage. We don't have technology leads/patch wranglers here, unlike other OSS projects and methodologies.) 2. they inevitably lead to out-of-band, off-the-dev-list communications to the author from third parties, including IP auditors, affected users who hit a bug, developers with patches to offer, etc. 3. they add non-ASF metrics such as who touched how many files, who has more merit, etc. Simply - our measure of participants comes from subversion commit history, the 'participants' or 'who we are' project page, and nothing much more. We summarize their contributions in CHANGES, but that list is rarely well maintained nor definitively complete. 4? w.r.t. style of specific authors, doesn't the project aim to have one consistent style? If author tags can encourage folks to adopt their own style in lieu of following a project-wide style, isn't this an issue? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Community Guidelines (was Code of Conduct)
Henri - I grok what you are saying. This isn't a Code of Conduct, it's a top-level description of our ethos. Two more inline... Henri Yandell wrote: On 6/28/07, Ted Husted [EMAIL PROTECTED] wrote: Some of the ASF Members have indicated a wish to draft a code of conduct. A working draft of a set of Community Guidelines is available on the incubator wiki, * http://wiki.apache.org/incubator/CodeOfConduct Any comments would be very welcome. So... I really dislike the BlogHer code of conduct, and what you've got too. It's hard to explain why, so now I've ranted out loud to my wife for a while, I'll try to see if I've got an explanation. I fully agree with the crapness of what led to said code of conduct. We shouldn't put up with people acting that way to a member of our community (blogging in this case, not apache) unless that's something they're signing up for. So biling Hani, sure. But harassing someone whose given no reason that they're into such things, no. The code of conduct is bad though. It's this thing that supposedly I'm meant to be saying Yes, I'll adhere to this code of conduct, but it is far too close to licensing and legal talk. What is a moral right? What is an obligation of confidentiality? Afaik I can do anything with anything I'm given unless someone indicates its confidential (where my employment ndas always seem to define lots as confidential etc). Same for much of it. The authors are trying to define play nice, but all they do is create a list of things that if I have to sign up for will mean someday that someone is going to accuse me of breaking said rule because they interpret the vague words in some other way to me. confidential is [EMAIL PROTECTED] It's for your eyes only - this goes back to the fact that individuals participate, not companies, not other orgs. That needs to be solidified into a code of conduct; you don't represent your employer, you wear a different hat here. What you read here (in private@) stays private, what you find out at work should be private to your work life. Folks need to know how to switch, and also wear hats. With play nice, it's obvious that we're all interpreting things, but with the attempted code of conduct there's an impression that it is definitive and that I'm supposed to understand it all. Slight side note. What's the punishment? Are we going to throw people out of our community for breaking this? Are we only going to throw them out if they sign up? Hell ya. Let me state that when various leaks of members@ level and higher material occured, I was personally read to pen a resolution to expel the idiot with no respect for the foundation. We are fortunate that in recent memory, when folks fucked up, they have admitted it and offered their mea culpas. That's terrific, I'm glad they knew (in hindsight) that they did the ASF a disservice. But I have no problem with a PMC turning off pmc access, commit access, or even un-subbing an obnoxious participant. We just had to do this at the wiki level in httpd. It happens, solve it, move on. Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Community Guidelines (was Code of Conduct)
On 6/30/07, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: This isn't a Code of Conduct, it's a top-level description of our ethos. Yes, that's how it turned out. I started out to research a code of conduct, and came back with a set of community guidelines that describe how we expect people to behave on our lists. (The context was hostile behavior, or behavior perceived to be hostile.) Two key points the community guidelines make is criticize the code, not the coder, and don't feed the trolls. I can remember multiple occasions when we've had to explain such things to people on different lists, and I believe it would help to have a cannonical reference. The example project guidelines and cultural principles were added to put the draft community guidelines into context. Though, we might not want to post all three items together as a block. * The Community Guidelines could be placed at apache.org under Get Involved, next to the Mailing List page. * The Example Project Guidelines could be placed at incubator.apache.org under Other Guides,. * The first part of the ASF Culture section could be merged with the Philosophy section of How the ASF Works, with the ASF Motto section being moved to it's own page, next to the Glossary of Apache-Related Terms http://apache.org/foundation/glossary.html. Hell ya. Let me state that when various leaks of members@ level and higher material occurred, I was personally read to pen a resolution to expel the idiot with no respect for the foundation. No need to pen a resolution, all we need is a 2/3's vote. Section 4.7. Termination from Membership. No member may have his, her or its membership terminated except by an affirmative vote of a two-thirds majority of the members of the corporation. But I have no problem with a PMC turning off pmc access, commit access, or even un-subbing an obnoxious participant. We just had to do this at the wiki level in httpd. It happens, solve it, move on. Since the PMC and its chair serve at the pleasure of the board, there's nothing in the bylaws about booting someone off a PMC. Though, I'd hope that we'd look for the same sort of 2/3 super-majority vote at the PMC level. If we didn't have that degree of consensus, then it might be better to just reboot the PMC and start over (or not). Of course, when a resource is public, our only recourse is to shun an obnoxious participant, since unsubbing someone that obnoxious will simply encourage more bad behavior under a new email address. We should try and be sure that our communities understand that Don't feed the trolls does work. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Community Guidelines (was Code of Conduct)
Ted Husted wrote: The example project guidelines and cultural principles were added to put the draft community guidelines into context. Though, we might not want to post all three items together as a block. Yea - I'm sort of confused. I'm looking to inject two more concepts, reinforce that you are you (not your company), that companies aren't here (thou there employees may be) they are participating as ASF folk, not as company X folk, and that what is private@ to the ASF doesn't leave the ASF. (Any more than we want you to share private stuff from your company here with the ASF). Respect privacy boundaries, and act as yourself, an individual participant, first. Not as an employee. We sort of start down that path in a few spots already, but didn't really bring that picture full circle yet. One other bit, shouldn't it be developer-friendly license terms? (That is, developers should be free to use the code however they like for whatever purpose it serves them, as opposed to FSF'isms that code has inherent freedom to be expressed. That's how I've described the AL/GPL divide in the past). Of course, when a resource is public, our only recourse is to shun an obnoxious participant, since unsubbing someone that obnoxious will simply encourage more bad behavior under a new email address. We should try and be sure that our communities understand that Don't feed the trolls does work. Oh ya. We've had those too - in fact it's been interesting that the banned wiki spammer suddenly started communicating on docs after their wiki keys were taken away. And maybe started to grok what they had been doing wrong. (Or not, heh.) It's more effective to ignore/shun, than to begin banning IPs from public mailing lists for misbehavior. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Community Guidelines (was Code of Conduct)
On Jun 28, 2007, at 8:32 PM, Craig L Russell wrote: I have a question about this part of the guidelines: Project source code and documentation must be donated to the ASF under a moin-www.png Contributor's License Agreement. Donated source code and documentation must carry the ASF copyright and be placed under the Apache License. Code and documentation donated to the ASF must be maintained on ASF hardware. Obtaining a non-exclusive ASF copyright on all material in the ASF repository is encouraged. I'd like to understand if the requirement is to donate code and documentation or to license it to ASF. I thought that the requirement was to simply license it to ASF under ASL v2.0. You are correct. The word donated here is wrong because licenses are not a donation, in spite of our habit of blurring the concept. Roy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Community Guidelines (was Code of Conduct)
On 6/28/07, Ted Husted [EMAIL PROTECTED] wrote: Some of the ASF Members have indicated a wish to draft a code of conduct. A working draft of a set of Community Guidelines is available on the incubator wiki, * http://wiki.apache.org/incubator/CodeOfConduct Any comments would be very welcome. So... I really dislike the BlogHer code of conduct, and what you've got too. It's hard to explain why, so now I've ranted out loud to my wife for a while, I'll try to see if I've got an explanation. I fully agree with the crapness of what led to said code of conduct. We shouldn't put up with people acting that way to a member of our community (blogging in this case, not apache) unless that's something they're signing up for. So biling Hani, sure. But harassing someone whose given no reason that they're into such things, no. The code of conduct is bad though. It's this thing that supposedly I'm meant to be saying Yes, I'll adhere to this code of conduct, but it is far too close to licensing and legal talk. What is a moral right? What is an obligation of confidentiality? Afaik I can do anything with anything I'm given unless someone indicates its confidential (where my employment ndas always seem to define lots as confidential etc). Same for much of it. The authors are trying to define play nice, but all they do is create a list of things that if I have to sign up for will mean someday that someone is going to accuse me of breaking said rule because they interpret the vague words in some other way to me. With play nice, it's obvious that we're all interpreting things, but with the attempted code of conduct there's an impression that it is definitive and that I'm supposed to understand it all. Slight side note. What's the punishment? Are we going to throw people out of our community for breaking this? Are we only going to throw them out if they sign up? Laws exist and work (as such) because we punish people who break them. The BlogHer code of conduct is useless afaict because there is no punishment. Being able to waggle fingers at someone and tell them they're breaking your code of conduct is useless. In our case, we actually can punish; so I'd be scared to see us define something like this. The blogging codes are harmless unless they're running your server, for us it wouldn't be. So on this I don't see the point. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Community Guidelines (was Code of Conduct)
Can someone suggest a patch? On 6/29/07, Roy T. Fielding [EMAIL PROTECTED] wrote: On Jun 28, 2007, at 8:32 PM, Craig L Russell wrote: I have a question about this part of the guidelines: Project source code and documentation must be donated to the ASF under a moin-www.png Contributor's License Agreement. Donated source code and documentation must carry the ASF copyright and be placed under the Apache License. Code and documentation donated to the ASF must be maintained on ASF hardware. Obtaining a non-exclusive ASF copyright on all material in the ASF repository is encouraged. I'd like to understand if the requirement is to donate code and documentation or to license it to ASF. I thought that the requirement was to simply license it to ASF under ASL v2.0. You are correct. The word donated here is wrong because licenses are not a donation, in spite of our habit of blurring the concept. Roy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Community Guidelines (was Code of Conduct)
I have a question about this part of the guidelines: Project source code and documentation must be donated to the ASF under a inline: moin-www.png Contributor's License Agreement. Donated source code and documentation must carry the ASF copyright and be placed under the Apache License. Code and documentation donated to the ASF must be maintained on ASF hardware. Obtaining a non-exclusive ASF copyright on all material in the ASF repository is encouraged. I'd like to understand if the requirement is to donate code and documentation or to license it to ASF. I thought that the requirement was to simply license it to ASF under ASL v2.0. Craig On Jun 28, 2007, at 1:56 PM, Ted Husted wrote: Some of the ASF Members have indicated a wish to draft a code of conduct. A working draft of a set of Community Guidelines is available on the incubator wiki, * http://wiki.apache.org/incubator/CodeOfConduct Any comments would be very welcome. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: Community Guidelines (was Code of Conduct)
Craig L Russell wrote: I have a question about this part of the guidelines: Project source code and documentation must be donated to the ASF under a Contributor's License Agreement. This just absolutely clarifies the intent of the author, it's the simplest method of conveying your-code to 'our-code' under clear license. Donated source code and documentation must carry the ASF copyright and be placed under the Apache License. Code and documentation donated to the ASF must be maintained on ASF hardware. Obtaining a non-exclusive ASF copyright on all material in the ASF repository is encouraged. I'd like to understand if the requirement is to donate code and documentation or to license it to ASF. I thought that the requirement was to simply license it to ASF under ASL v2.0. Either 1. it's really tiny - 8 line patches and so forth, and we accept without a CLA (lots of dev@, issues.a.o sorts of input from the community). 2. it's substantial, and we hope they will help maintain/keep committing, and get a CLA from them to reflect both. 3. it's actually owned by a company or individual who we don't expect to commit in the future. Otherwise it isn't ASF code. So -if- it is still accepted by the project (treat this as an external IP import), it comes in with its NOTICE of copyright, and its LICENSE (ASF or otherwise acceptable license). Even as it evolves, it's providence is still from external IP. It's also not a matter of their licensing it 'to the ASF', as licensing it under the AL (not ASL ;-) offers that license to the world including the ASF. Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Community Guidelines (was Code of Conduct)
William A. Rowe, Jr. wrote: Craig L Russell wrote: Donated source code and documentation must carry the ASF copyright and be placed under the Apache License. Code and documentation donated to the ASF must be maintained on ASF hardware. Obtaining a non-exclusive ASF copyright on all material in the ASF repository is encouraged. I'd like to understand if the requirement is to donate code and documentation or to license it to ASF. Either 1. it's really tiny - 8 line patches and so forth, and we accept without a CLA (lots of dev@, issues.a.o sorts of input from the community). 2. it's substantial, and we hope they will help maintain/keep committing, and get a CLA from them to reflect both. 3. it's actually owned by a company or individual who we don't expect to commit in the future. ... 3. ... We simply request a Code Grant to make the license explicit and keep a record of the license. This is how most pre-existing IP enters the incubator. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
