1364268 - Update copy in https://www.mozilla.org/en-US/about/governance/policies/participation/

Status: RESOLVED FIXED

(www.mozilla.org :: Pages & Content, enhancement)

Description

[Eric Renaud [:erenaud]]

Final copy is here - https://docs.google.com/document/d/1F15QP25g0oMNCjKfwhexNtB3ClpLUVsw5GbHnJVVf5k/edit

Comment 1

[Lizz Noonan - she/her (:lizzn)]

I'm currently adding the EN here: https://github.com/mozilla/diversity/

Comment 2

[Lizz Noonan - she/her (:lizzn)]

Pull request: https://github.com/mozilla/diversity/pull/50

Craig: Do you want me to create sub-folder in the CPG directory for the other languages?

Comment 3

[Craig Cook (:craigcook)]

(In reply to Lizz Noonan - she/her (:lizzn) from comment #2)
> Pull request: https://github.com/mozilla/diversity/pull/50
> 
> Craig: Do you want me to create sub-folder in the CPG directory for the
> other languages?

Hmm... right now this page is just a standard template in Bedrock and I've updated the content the old fashioned way. We can set it up to fetch markdown from the diversity repo (the same way we process legal docs) but that'll take a little bit more effort.

If the desire is to get the updated guidelines published as soon as possible we should proceed with what we have now and then start working on switching it over to external markdown in the very near future (and we should probably spin that work off into another bug).

Comment 4

[Lizz Noonan - she/her (:lizzn)]

Sure, that's fine with me!

Comment 5

[Craig Cook (:craigcook)]

Attachment: Github pull request https://github.com/mozilla/bedrock/pull/4838

Comment 6

[Peiying Mo [:CocoMo]]

> 
> Hmm... right now this page is just a standard template in Bedrock and I've
> updated the content the old fashioned way. We can set it up to fetch
> markdown from the diversity repo (the same way we process legal docs) but
> that'll take a little bit more effort.
> 
> If the desire is to get the updated guidelines published as soon as possible
> we should proceed with what we have now and then start working on switching
> it over to external markdown in the very near future (and we should probably
> spin that work off into another bug).

I vote for this solution  Get it done now and work on moving it to the proper place at a later time.

Comment 7

[Peiying Mo [:CocoMo]]

@Lizz, please comment if my assumption is incorrect and that you prefer we start with markdown format.

Comment 8

[Lizz Noonan - she/her (:lizzn)]

(In reply to Peiying Mo [:CocoMo] from comment #6)
> > 
> > Hmm... right now this page is just a standard template in Bedrock and I've
> > updated the content the old fashioned way. We can set it up to fetch
> > markdown from the diversity repo (the same way we process legal docs) but
> > that'll take a little bit more effort.
> > 
> > If the desire is to get the updated guidelines published as soon as possible
> > we should proceed with what we have now and then start working on switching
> > it over to external markdown in the very near future (and we should probably
> > spin that work off into another bug).
> 
> I vote for this solution  Get it done now and work on moving it to the
> proper place at a later time.

Yes, I agree. Thanks Peiying and Craig.

Comment 9

[Peiying Mo [:CocoMo]]

Great.

@Craig, I assume you are waiting for someone to review your code and approve it.  Could you assign someone to that?  This should be pretty straight forward compared to others bedrock PRs.

Also, we will work with a localization agency instead of going through communities, who will have a chance to review the files post translation.  I am trying to weigh my options:

1).  should I process it to to create a .lang file so it is Pontoon friendly?
2).  should I leave it as is, and pass the file to the agency to work on it with codes embedded in the file? The agency will have tools to process it and protect the codes/markups.  They will return the file just like en-US.

From the perspective of production push, is it better to stick to option 1, especially if the communities want to make changes, they still can, and I can do my daily localization production push, including this one?

Please advise.

Comment 10

[Craig Cook (:craigcook)]

(In reply to Peiying Mo [:CocoMo] from comment #9)

> From the perspective of production push, is it better to stick to option 1,
> especially if the communities want to make changes, they still can, and I
> can do my daily localization production push, including this one?

Hmm... anything we put into .lang files now would soon be obsolete when we switch over to external markdown, or we'd have to figure out how to migrate those translations. Also I'd hate for a volunteer localizer to put a lot of effort into translating all that text if we already have an agency working on that particular language.

Perhaps it's best not to extract the strings at all, remove the current Japanese translation, and make the page English-only in the short term until we can switch over to markdown to add the agency translations. which we can hopefully do pretty soon. Then we can open it up to the l10n community after that.

Comment 11

[Peiying Mo [:CocoMo]]

This document is long overdue to for a release.  The localized versions will be in a select few languages requested by the participation/D&I teams.  Because of the "legal" tone in the document, this will be done by an agency. L10n communities can review and fix anything they see fit post initial translation.  This is the current plan.  I am thinking while the agency work on the localized versions, you can help the team find a solution like the one for legal team.  This way English and localized versions can be pushed to production at the same time. If this may take some time, let's release English first.

For the time being, can I just use what Lizz has created and go from there?

Comment 12

[[github robot]]

Commits pushed to master at https://github.com/mozilla/bedrock

https://github.com/mozilla/bedrock/commit/8919502cb69ebef3980cad296bf5ce5a98873cad
[fix bug 1364268] Update Community Participation Guidelines

https://github.com/mozilla/bedrock/commit/e51806e1e7a3c37cb48da9e1cdf88c581c1bdb8e
Merge pull request #4838 from craigcook/bug-1364268-update-participation-guidelines

[fix bug 1364268] Update Community Participation Guidelines

Comment 13

[Peiying Mo [:CocoMo]]

@Craig, one string is not exposed: https://github.com/mozilla/bedrock/pull/4838/files#diff-4e227690fbf557b35ab9403a58d9734aR473.

Comment 14

[Craig Cook (:craigcook)]

(In reply to Peiying Mo [:CocoMo] from comment #13)
> @Craig, one string is not exposed:
> https://github.com/mozilla/bedrock/pull/4838/files#diff-
> 4e227690fbf557b35ab9403a58d9734aR473.

D'oh! Sorry I missed that. I've submitted a PR https://github.com/mozilla/bedrock/pull/4871

Comment 15

[[github robot]]

Commits pushed to master at https://github.com/mozilla/bedrock

https://github.com/mozilla/bedrock/commit/9bf8c0f4d2ca2cdcb01eeab6f8cc573c86c2211d
[bug 1364268] Participation guidelines, enclose string for l10n

https://github.com/mozilla/bedrock/commit/5c9fb9210b0d6636fa4a4c093892ed89791c02d4
Merge pull request #4871 from craigcook/bug-1364268-update-participation-guidelines

[bug 1364268] Participation guidelines, enclose string for l10n

Comment 16

[Lizz Noonan - she/her (:lizzn)]

Hi Craig and Peiying, 

We have a paragraph to add to the page from the Legal Team around updates to the CPG:

Mozilla may amend the Community Participation Guidelines from time to time and may also vary the procedures it sets out where appropriate in a particular case. Your agreement to comply with the CPG will be deemed agreement to any changes to it.  In case Mozilla amends the CPG, the updated version can be found at http://www.mozilla.org/about/governance/policies/participation/.  You can sign up for push updates by subscribing to https://groups.google.com/d/forum/mozilla-cpg.  This policy does not form part of any Mozilla employee’s contract of employment or otherwise have contractual effect. 

Can we please add this to the bottom of the CPG page? LMK. 

Thanks!

Comment 17

[Peiying Mo [:CocoMo]]

I would add the TLA of CPG right after the full name is mentioned here, or amend the document upon its first reference.

CPG is not CPG in other languages. If this is the above "official" wording, it needs to be modified.

Comment 18

[Peiying Mo [:CocoMo]]

Hello Lizz,  

The paragraph needs to be modified for the CPG reference. This is not a known TLA, so it should be clearly stated in the doc, such as "Community Participation Guide (or the Guide)"... something along this line.

Please confirm if the above provided paragraph is signed off by legal, or we can't proceed with it.

Comment 19

[Craig Cook (:craigcook)]

Ping.

We have two options, I think:

1. Amend the first paragraph with "(...) require all those who participate to agree and adhere to these Community Participation Guidelines (CPG) in order to help us create (...)"

2. Tweak the new disclaimer with "Mozilla may amend the Community Participation Guidelines (CPG) from time to time (...)"

Either one will satisfy defining the new acronym. I'm not sure what the rules are for translating acronyms, but I think this one is pretty informal so maybe locales can make their own equivalent acronyms. The German "Richtlinien für das Mitwirken in der Community" might be "RMC", for example.

Comment 20

[Peiying Mo [:CocoMo]]

Any update on this? We need some guidance.

Comment 21

[Peiying Mo [:CocoMo]]

@Craig, I noticed that hi-IN is not on production but it is on staging: https://www-dev.allizom.org/hi-IN/about/governance/policies/participation/

https://www.mozilla.org/about/governance/policies/participation/.

Comment 22

[Craig Cook (:craigcook)]

(In reply to Peiying Mo [:CocoMo] from comment #21)
> @Craig, I noticed that hi-IN is not on production but it is on staging:
> https://www-dev.allizom.org/hi-IN/about/governance/policies/participation/

It's appearing on www-dev because all locales are active in dev mode but it's not yet available on staging, which more closely mirrors production: https://www.allizom.org/hi-IN/about/governance/policies/participation/ redirects to en-US

Looks like there are two strings keeping this from showing up, if I'm reading this right? 
https://l10n.mozilla-community.org/langchecker/?locale=hi-IN#mozorg/about/governance/policies/participation.lang

Comment 23

[Peiying Mo [:CocoMo]]

@Craig, you are right! I thought they fixed it.  Let me ping the team.

Comment 24

[Lizz Noonan - she/her (:lizzn)]

(In reply to Peiying Mo [:CocoMo] from comment #20)
> Any update on this? We need some guidance.

Hi Peiying! Thanks for your patience, I thought I had already cleared this needs info. I think we should change the disclaimer to Community Participation Guidelines. Shoshanna Issac from Legal wrote the amendment paragraph, so it is approved. Please LMK if you need any other info from me. Thank you!

Comment 25

[Casey McGill [NEED INFO ME]]

Hey team, chiming in here for the legal team. It looks like the rest of the document refers to them as "guidelines" so in the interest of consistency can we change the text to say :

Mozilla may amend the guidelines from time to time and may also vary the procedures it sets out where appropriate in a particular case. Your agreement to comply with the guidelines will be deemed agreement to any changes to it.  In case Mozilla amends the guidelines, the updated version can be found at http://www.mozilla.org/about/governance/policies/participation/.  You can sign up for push updates by subscribing to https://groups.google.com/d/forum/mozilla-cpg.  This policy does not form part of any Mozilla employee’s contract of employment or otherwise have contractual effect.

Comment 26

[Craig Cook (:craigcook)]

One last detail... this new disclaimer should probably have some kind of heading to separate it from the "License and attribution" section above it. Maybe "Updates" or "Amendments" or even "Disclaimer"?

Comment 27

[Peiying Mo [:CocoMo]]

Good point, Craig. 

Also, the link about update is referring to the very doc the user is already reading. Should we just say "the updated version can be found here"?

Comment 28

[Craig Cook (:craigcook)]

Actually, one more thing... How should we treat this new text for l10n? I can wrap it in a special tag so this one section wouldn't appear until it's translated but the rest would still be available. Unless we need to consider this a required part of the complete policy (i.e. it's incomplete without it). In that case we should invalidate any current translations until they can incorporate the new section. Thoughts, anyone?

Comment 29

[Craig Cook (:craigcook)]

(In reply to Peiying Mo [:CocoMo] from comment #27)
> Good point, Craig. 
> 
> Also, the link about update is referring to the very doc the user is already
> reading. Should we just say "the updated version can be found here"?

I think we want to include the full URL explicitly so the document is more "portable". Could be printed, republished on another site, etc.

Comment 30

[Peiying Mo [:CocoMo]]

@Casey, thanks for the clarification.

@Craig, all the locales are on production already. (unlike mozorg stuff, ;-P)

Comment 31

[Craig Cook (:craigcook)]

(In reply to Peiying Mo [:CocoMo] from comment #30)
 
> @Craig, all the locales are on production already. (unlike mozorg stuff, ;-P)

But this is a new string so it would appear in English on an otherwise translated page. If we wrap it in an l10n tag to avoid that (like we usually do for string changes), that might mean those translated versions of the guidelines are considered incomplete until they can translate the new part. I know it's not a legal contract but it's a policy we enforce so I just want to be very careful and deliberate about any changes.

If one portion of a policy is missing can someone truly agree to the policy? For instance the line "Your agreement to comply with the guidelines will be deemed agreement to any changes to it." ... if that part wasn't available in your language at the time you agreed, could you be held accountable for violating future amendments? Are we creating a weird loophole if we show this document in different states of completeness for different languages, even temporarily? Of course I could just be overthinking all this.

So I think it's a question for the policy and/or legal folks: 
A) If the new section is a required part of the complete policy, we can deactivate any current translations until they're complete again. 
B) If the new section is optional, we can wrap it in a tag to hide just that section it until it's translated.

Comment 32

[Peiying Mo [:CocoMo]]

@Craig, good questions.

For the 2nd part, what i can do is that i can hold off push to production on my end - unlike other legal docs, I do the pushes only when it is complete.  I can monitor the progress for each locale. Also because of the content, the work was done by an agency and reviewed by communities afterwards.

Comment 33

[Casey McGill [NEED INFO ME]]

Hey Craig, thanks for flagging that. As for the title of the section this is a pretty typical language for our different terms of service notices and we typically call it "Modifications to these Terms". 

See example here : https://www.mozilla.org/en-US/about/legal/terms/mozilla/

With the timing, we've never really seen localization on a blocker for notices (with a few exceptions) so I'm not sure if that would be the case here. I suggest we go with Peiying's suggestion of holding off on the push to production of the localized versions until we get the translated sections back.

Comment 34

[Craig Cook (:craigcook)]

(In reply to Casey McGill [NEED INFO ME] from comment #33)
> Hey Craig, thanks for flagging that. As for the title of the section this is
> a pretty typical language for our different terms of service notices and we
> typically call it "Modifications to these Terms".

Ok, I'll go with "Modifications to these guidelines"


> With the timing, we've never really seen localization on a blocker for
> notices (with a few exceptions) so I'm not sure if that would be the case
> here. I suggest we go with Peiying's suggestion of holding off on the push
> to production of the localized versions until we get the translated sections
> back.

Sounds good. This page is kind of a special case as it's not-quite-a-contract so I'm perhaps overly cautious. 

I'll have a pull request for this update shortly.

Comment 35

[Craig Cook (:craigcook)]

Attachment: Github pull request https://github.com/mozilla/bedrock/pull/5010

Comment 36

[[github robot]]

Commits pushed to master at https://github.com/mozilla/bedrock

https://github.com/mozilla/bedrock/commit/0c5719c06aad955f4effc4d8c2fb3b7152cfb29c
[fix bug 1364268] Add modification section to participation guidelines

https://github.com/mozilla/bedrock/commit/b4fb9b385a15977770a4263387513aee947c12b1
Merge pull request #5010 from craigcook/bug-1364268-participation-guidelines

[fix bug 1364268] Add modification section to participation guidelines