Thomas Dalton writes:
2008/6/22 Mike Godwin mgodwin@wikimedia.org:
I don't think education is exclusive as binding policy. Any policy we publish is going to have a binding effect, to the extent that people rely on our representations about what we do. That's why we have taken the pains to make the policy match our actual practice as completely as possible.
You'll note, I said "primarily as binding policy". I know it is binding policy now, but that's not its primary function, its primary function is clearly one of education, and that should be changed.
I am not sure what it is you are saying should be changed (it's unclear which function is referenced by "that"), but there is no question that the document has to function both as a statement of binding policy and as an educational document. Attempting to separate one from the other is asking for trouble down the line.
We considered for a while separating the current policy into a statement of policy and an FAQ. That would have "solved" the length problem, more or less, but it also would create a problem, since the FAQ itself would have functioned as a legally binding public promise as well. In other words, it would have seemed to be more elegant but would have raised potentially more legal problems, especially to the extent that the public relied on representations in the FAQ rather than in the policy statement proper.
We really did review a range of options before taking the particular approach we took, and we took this approach in full awareness that we'd end up with a longer work product. But that turns out to be the more legally prudent course to take.
--Mike
2008/6/23 Mike Godwin mgodwin@wikimedia.org:
Thomas Dalton writes:
2008/6/22 Mike Godwin mgodwin@wikimedia.org:
I don't think education is exclusive as binding policy. Any policy we publish is going to have a binding effect, to the extent that people rely on our representations about what we do. That's why we have taken the pains to make the policy match our actual practice as completely as possible.
You'll note, I said "primarily as binding policy". I know it is binding policy now, but that's not its primary function, its primary function is clearly one of education, and that should be changed.
I am not sure what it is you are saying should be changed (it's unclear which function is referenced by "that"),
"That" refers to the fact that the document is primarily educational, rather than actual policy.
but there is no question that the document has to function both as a statement of binding policy and as an educational document. Attempting to separate one from the other is asking for trouble down the line.
There is question - I question it. Policy and documentation are very different things. Trying to combine the two is very difficult and, in my opinion, doomed to failure for the reasons already given.
We considered for a while separating the current policy into a statement of policy and an FAQ. That would have "solved" the length problem, more or less, but it also would create a problem, since the FAQ itself would have functioned as a legally binding public promise as well. In other words, it would have seemed to be more elegant but would have raised potentially more legal problems, especially to the extent that the public relied on representations in the FAQ rather than in the policy statement proper.
I guess that depends on how well you write it. The policy should describe what the WMF commits to doing, the FAQ should explain why. It's not easy to cleanly separate the two, but I believe it is possible. Certainly, the explanations given in the FAQ will be used by anyone interpreting the policy, but the answer to that is to make the policy are precise as possible so there is as little room for interpretation as possible - as you should do with any legal document (that's why we put up with legalese, after all).
We really did review a range of options before taking the particular approach we took, and we took this approach in full awareness that we'd end up with a longer work product. But that turns out to be the more legally prudent course to take.
Legality aside, we're telling you, as real people, that this policy simply will not work. It doesn't matter how prudent it is, if it doesn't work, it's useless.
I've set up a draft version of the policy to demonstrate what issues I think can be addressed:
http://meta.wikimedia.org/wiki/User:Avruch/PPdraft
It addresses some issues raised on this list and some I identified, particularly:
* Consistent terminology: Projects are variously referred to as projects, wikis, WMprojects, WMProjects, Wikiprojects, etc. Wikiprojects (to take an example) means something else entirely at least on the English Wikipedia, and so should probably be avoided. In most cases I've changed the usage to simply "project" or "projects." Wikimedia Foundation is variously Wikimedia, WMF and Wikimedia Foundation (although I didn't see the term WMF defined, it may have been). I've made most of those instances consistent.
* Editing for length: I think there are a number of paragraphs that could be condensed without losing readability or meaning. I've done a bit of that, most especially in the first half. Might not be able to save a huge amount of text this way, but there are definitely opportunities.
* Formatting: A couple of formatting issues, actually. I've altered the header format to flow better and look better when displayed on Wiki, and made the use of headers, bullets, subheaders and bolding more consistent. I've removed the "Introduction" header just as a style difference, since its the first text in the document anyway.
Mainly I think the policy works. Its definitely longer than most privacy policies, but its also far more comprehensively written. A couple good reasons for that - the Foundation has an opportunity to collect a lot more user data than most other sites, and its policy is aimed at limiting the Foundation and protecting the user rather than allowing maximum flexibility for the corporation and its protection. All it really needs is some good copyediting - for length, internal consistency and clarity.
If you want, this version can be copied into the other draft version as a revision (and then reverted) so that the differences can be easily seen.
Nathan
Thank you, Nathan. I would add that basic tech background should be separated out into another document; and the use cases and motivation/intent sections should be in a long appendix, leaving the actual Polcy section as compact as possible.
I also left comments on the draft's talk page re: important details that are being left out. SJ
On Mon, Jun 23, 2008 at 5:39 PM, Nathan nawrich@gmail.com wrote:
I've set up a draft version of the policy to demonstrate what issues I think can be addressed:
http://meta.wikimedia.org/wiki/User:Avruch/PPdraft
It addresses some issues raised on this list and some I identified, particularly:
- Consistent terminology: Projects are variously referred to as projects,
wikis, WMprojects, WMProjects, Wikiprojects, etc. Wikiprojects (to take an example) means something else entirely at least on the English Wikipedia, and so should probably be avoided. In most cases I've changed the usage to simply "project" or "projects." Wikimedia Foundation is variously Wikimedia, WMF and Wikimedia Foundation (although I didn't see the term WMF defined, it may have been). I've made most of those instances consistent.
- Editing for length: I think there are a number of paragraphs that could
be condensed without losing readability or meaning. I've done a bit of that, most especially in the first half. Might not be able to save a huge amount of text this way, but there are definitely opportunities.
- Formatting: A couple of formatting issues, actually. I've altered the
header format to flow better and look better when displayed on Wiki, and made the use of headers, bullets, subheaders and bolding more consistent. I've removed the "Introduction" header just as a style difference, since its the first text in the document anyway.
Mainly I think the policy works. Its definitely longer than most privacy policies, but its also far more comprehensively written. A couple good reasons for that - the Foundation has an opportunity to collect a lot more user data than most other sites, and its policy is aimed at limiting the Foundation and protecting the user rather than allowing maximum flexibility for the corporation and its protection. All it really needs is some good copyediting - for length, internal consistency and clarity.
If you want, this version can be copied into the other draft version as a revision (and then reverted) so that the differences can be easily seen.
Nathan _______________________________________________ foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
Nathan wrote:
I've set up a draft version of the policy to demonstrate what issues I think can be addressed:
http://meta.wikimedia.org/wiki/User:Avruch/PPdraft
It addresses some issues raised on this list and some I identified, particularly:
- Consistent terminology: Projects are variously referred to as projects,
wikis, WMprojects, WMProjects, Wikiprojects, etc. Wikiprojects (to take an example) means something else entirely at least on the English Wikipedia, and so should probably be avoided. In most cases I've changed the usage to simply "project" or "projects." Wikimedia Foundation is variously Wikimedia, WMF and Wikimedia Foundation (although I didn't see the term WMF defined, it may have been). I've made most of those instances consistent.
Hello
Just on that particular point, it seems that within the organization, the terminology now generally used is "wikimedia projects".
I do not think using "projects" is a good idea as the term is not specific enough. Better keep this term to describe stuff such as "DVD publishing" or "PDF generation" etc...
However, I object to the use of the term "wikimedia foundation projects" or "wmf projects". WMF do not own the projects any more than other organizations, and the existence of most projects is actually older than the existence of the Foundation. I'll add that in people's mind, it could tend to give more weight to the idea that WMF is the one in charge (increase legal exposure).
ant
2008/6/23 Florence Devouard Anthere9@yahoo.com:
Just on that particular point, it seems that within the organization, the terminology now generally used is "wikimedia projects".
I do not think using "projects" is a good idea as the term is not specific enough. Better keep this term to describe stuff such as "DVD publishing" or "PDF generation" etc...
"Wikimedia sites"?
On Mon, Jun 23, 2008 at 4:16 PM, Thomas Dalton thomas.dalton@gmail.com wrote:
2008/6/23 Mike Godwin mgodwin@wikimedia.org:
but there is no question that the document has to function both as a statement of binding policy and as an educational document. Attempting to separate one from the other is asking for trouble down the line.
There is question - I question it. Policy and documentation are very different things. Trying to combine the two is very difficult and, in my opinion, doomed to failure for the reasons already given.
I have to agree with Mike here that a (good) privacy policy has to function "both as a statement of binding policy and as an educational document" (ignoring the part about whether or not there's "no question").
In fact, I'd say the *primary* purpose of a privacy policy is as an educational document. If all the organization wants to do is bind itself to something, a private board resolution would suffice. I think Mike should be applauded for trying to create an educational document rather than a bunch of legalese.
(I guess in some jurisdictions privacy policies are legally required so maybe the purpose could be to fulfill a legal requirement. Or maybe the purpose could be to keep browsers from popping up warnings about the lack of a privacy policy. But still, the base reason is that the public has an ethical right to know these things - a right to be educated.)
We considered for a while separating the current policy into a statement of policy and an FAQ. That would have "solved" the length problem, more or less, but it also would create a problem, since the FAQ itself would have functioned as a legally binding public promise as well. In other words, it would have seemed to be more elegant but would have raised potentially more legal problems, especially to the extent that the public relied on representations in the FAQ rather than in the policy statement proper.
I guess that depends on how well you write it. The policy should describe what the WMF commits to doing, the FAQ should explain why.
Why couldn't the FAQ *be* the current draft policy? Then all that's needed is a summary, which becomes the "privacy policy". And then it isn't a problem if the FAQ is legally binding, because it commits the WMF to no more than the WMF was going to commit to anyway. Or if you don't want to call it a FAQ, because it's not in standard FAQ format, call it "privacy policy (long version)" and "privacy policy (short version)".
Or would it take too much time and effort (also read: cost) to come up with a Godwin-approved shortened privacy policy? That's the only argument I can see against it, since Mike has already seemed to agree it's possible to have a shorter "statement of policy".
Just brainstorming a solution that maybe can solve both points of view. Feel free to ignore me, or not.
Legality aside, we're telling you, as real people, that this policy simply will not work. It doesn't matter how prudent it is, if it doesn't work, it's useless.
I certainly don't agree that it's "useless". A privacy policy is never going to make particularly fun reading material. A shorter policy would probably be more useful, not to mention more educational, but a long policy isn't "useless".
This said, I've had to skim the new draft rather than read it in depth. I'll probably get to that later. Sorry, Florence, non-ideal world and all that.
wikimedia-l@lists.wikimedia.org