On Tue, Mar 22, 2011 at 5:24 PM, Marvin Humphrey <[email protected]> wrote: > Hello, Henri, > > Thanks for the thoughtful response. I'm dividing my reply across two emails; > this one to cover what kind of product might emerge from this discussion and > where it might live, and the other to cover content. > > On Mon, Mar 21, 2011 at 01:01:24AM -0700, Henri Yandell wrote: >> It's a meritocracy; by stepping up with this email you've already >> started the project. Stay quietly persistent and keep it going (and I >> don't see why it can't stay on community@). > > At some point, I'd like to see this sample open source policy published on an > ASF website. I can think of three potential homes for it: legal affairs, dev, > and community. > > It seems plausible that legal affairs might be consulted at some point, but I > think this policy is distinct from its mission. Legal affairs is concerned > with activities that involve the ASF and IP licensed to the ASF directly. The > adoption of this sample policy would govern the relationship between a company > and its employees; the ASF would not be involved. It's akin to projects > outside the ASF using the Apache License or our CLAs... > > http://www.apache.org/foundation/licence-FAQ.html#My-License > http://www.apache.org/foundation/licence-FAQ.html#CLA-Usage > > ... except that the ASF would never actually use this document. Legal affairs > expertise is a limited resource, and if we don't have skin in the game, I'm > hesitant to suggest that it live there.
I'll challenge that one. The ASF employ individuals to develop, and they contribute back as a part of their job. If you're looking for a liberal policy, I suspect documenting the policy at the ASF would be pretty damn liberal :) So potential goal there - your liberal policy would have to stretch to the extremes of the ASF and other foundation employers. > For similar reasons, www.apache.org/dev might not be ideal. The dev site is > aimed at individual developers contributing to the ASF and engaging in ASF > governance activities. The target audience for this document would be IT > management. It might be brought to the attention of management by developers > who want to contribute to the ASF, but the there's a huge amount of material > on the dev site that wouldn't be relevant for the people we'd want to reach. > > I've looked around the community.apache.org website, and while there is not an > obvious home for it there, it's an interesting question whether a place could > be carved out for it. Trawling through email archives, past board reports, > and blog entries, I see that coordinating Google Summer of Code has been a > major focus, and that questions have been asked like "How might we attract > more technical writers to the ASF?". This seems like a similar outreach > activity, intended to bring more people to the ASF and make it easier for them > to contribute. The primary value would be in decreasing the time it takes for a company to go from user to contributor to committer-employer, incubator-source and/or sponsor. > Perhaps if we can craft a document of suitable quality, the Community PMC > could be persuaded to assume responsibility for publishing it and voting to > "release" it once it becomes mature enough. Call it the "Apache Community > Open Source Policy 0.1"? I'd challenge the statement >> Find a wiki and start documenting. :) > > I'm inclined to compile a draft/outline and open a JIRA issue. There has been > enough material in this thread to get started. Charge along :) > I don't think the policy itself should be developed on a wiki because we'd > potentially get contributions from people without CLAs on file, and I'd like > the ASF to have full freedom to use the material that comes out this process. > (I'm sure you of all people grok the licensing limitations of wiki documents, > though, so I've probably misunderstood your suggestion.) More that I'm less concerned by having CLAs on file to peer-write a document than I am to writing code. :) If someone ends up writing some huge part without a CLA, it's auditable and we can ask them to sign one. The value a wiki has for document development far blows away the pain of asking one person to sign a CLA. Doing this in a JIRA would be less likely to succeed imo; there's no existing lure to contribute so it'll be harder to get involvement than a patch would. Hen --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
