[IRT.RegDataPolicy] [Ext] Edits to One Doc

[Sarah Wyld]

Good morning team,

I definitely agree that we should not**use "edit" mode, as that method
makes it very difficult to identify changes. Personally I find "suggest"
mode the best, because changes can be entered inline and are clearly
visible as modified text along with who made the change, and also
comments can be added as needed. If the group would prefer to not use
inline changes and rely only on comments, we can decide as a group and
I'll of course follow whatever method we select.

That said, I would ask that group members do not reject the changes that
have already been submitted. It's important that everyone's
contributions be equally respected and remain visible to the team;
rejection of comments must not be a unilateral decision and is instead
at the discretion of the team as a whole.

Thank you.

-- 
Sarah Wyld
Domains Product Team
Tucows
+1.416 535 0123 Ext. 1392

 

On 11/19/2019 5:39 PM, Dennis Chang wrote:
>
> Thanks Laureen for the suggestion.
>
> I’ve received same suggestion from others so please don’t feel as you
> are in a unique situation.
>
>  
>
> When we were working with smaller individual documents, the way were
> doing it was efficient.
>
>  
>
> Now that we have a larger document and many more people are
> commenting, I believe that your suggested way will work better for us.
>
> This way we are always clear on what the “baseline” is.
>
>  
>
> This is very important as the GNSO Council Liaison he is monitoring
> the IRT’s level of agreement or separation.
>
> Remember that IRT’s main role is to determine if the proposed
> implementation is consistent with the recommendation.
>
>  
>
> There are countless ways to implement and we will defer on the ways of
> preference.
>
> This shouldn’t be confused with a “better.”
>
> Especially, as we move closer to public comment.
>
>  
>
> The Public Comment version may lack perfection in language but if we
> can convey the implementation approach clearly, we can proceed.
>
> Please note that the IRT work will continue with detail work during
> the public comment period.
>
>  
>
> Tomorrow, we’ll have a brief discussion about this but without a
> strong objection from anyone, I will change the collaboration
> methodology as suggested by Lauren here.
>
>  
>
> Thanks
>
> Dennis Chang
>
>  
>
> *From: *"Kapin, Laureen" <LKAPIN at ftc.gov>
> *Date: *Tuesday, November 19, 2019 at 14:02
> *To: *"IRT.RegDataPolicy at icann.org" <irt.regdatapolicy at icann.org>
> *Cc: *Dennis Chang <dennis.chang at icann.org>
> *Subject: *[Ext] Edits to One Doc
>
>  
>
> Hi folks,
>
>  
>
>     I’m finding it a bit challenging when reviewing the one doc
>     (Google doc).  In particular, while some folks edit via comments,
>     others edit the document directly.  Is there a convention we’re
>     supposed to follow?  In other ICANN WGs folks are encouraged NOT
>     to edit the document directly but rather give input via comments. 
>     In part, using the comment function is preferred because otherwise
>     it’s difficult to identify the editor.
>
>  
>
> Might we discuss some agreed upon ground rules going forward?  Thanks
> and apologies if I’ve missed prior discussions on this issue. 
>
> /  Sent via phone. /
>
> /  Please excuse typos and/or/
>
> /  unintended auto-correct outcomes./
>
>  
>
> *Laureen Kapin, Counsel*
>
> *Int’l Consumer Protection*
>
> *Federal Trade Commission*
>
>  
>
>  
>
>  
>
>  
>
>  
>
>
> _______________________________________________
> IRT.RegDataPolicy mailing list
> IRT.RegDataPolicy at icann.org
> https://mm.icann.org/mailman/listinfo/irt.regdatapolicy
>
> _______________________________________________
> By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/irt.regdatapolicy/attachments/20191120/d9819e77/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://mm.icann.org/pipermail/irt.regdatapolicy/attachments/20191120/d9819e77/signature.asc>