Mark Fernandes's improvements to the main GitHub terms and conditions #204

ghost · 2019-12-06T18:52:25Z

Please contact me if you disagree with any of my changes or you are unsure about any of them.

I use the general rule of thumb that less is better.

No need to say things like 'thank you'. If you want to say 'thank you', say it on your home page. People have little time, and want to spend as little time as possible reading user agreements such as this one.

Sometimes I've changed the ordering of statements because it makes for easier comprehension.

Sometimes I've just taken text out that is unnecessary.

I've tried to make changes so that for the vast majority of your users, it is quicker to get through them. Eg. majority of users probably don't use the APIs, so I've changed the terms so that you aren't forced to read the terms relating to the APIs if it is not relevant to you.

On the face of it, it may seem better to inform users about everything so that they are fully informed. However, in reality, users (especially ones not representing organisations), find it hard to mentally keep in mind all of the details of a user agreement. This means that informing them about everything can actually mean that they are less aware rather than more aware. If you try to be more selective with what you communicate, they can end-up being in fact more informed because they find the communication less unwieldy.

Using bullet points can make for better comprehension because it is generally a better visual organisation of information.

Sometimes, I've moved text so that a 'you can skip the rest of this section' statement can be made. So what happens, is that you read important stuff at the top (text sometimes moved to the top), and then you hit such a skipping statement so that you can skip the rest of the section.

Sometimes sentences have been combined to say the same thing with less words, in hopefully a clearer way. On the other hand, at least in one place I've split a very long-winded sentence into a few sentences, to make for easier comprehension. You find such very long-winded sentences in legal contracts. Even though they may be legally sound, they are generally very difficult to read.

Most of the changes should be easy to understand.

Further Advice

You can:

look at the advice I gave to Microsoft regarding one of their terms and conditions documents, that can be accessed by going to: https://answers.microsoft.com/en-us/skype/forum/all/processing-the-microsoft-services-agreement-legal/e104804e-c2c0-413f-b8e5-180a2b029415 .
look at how the BBC website terms and conditions (https://www.bbc.co.uk/usingthebbc/terms/) are arranged, and try to draw inspiration from them, in order to simplify the presentation, and improve the accessibility of, your terms.

KOLANICH · 2019-12-06T19:10:54Z

Policies/github-terms-of-service.md


 #### 2. Required Information
-You must provide a valid email address in order to complete the signup process. Any other information requested, such as your real name, is optional, unless you are accepting these terms on behalf of a legal entity (in which case we need more information about the legal entity) or if you opt for a [paid Account](#k-payment), in which case additional information will be necessary for billing purposes.
+The following information is required:


👍 I guess you need to add only

Yes, it can be a good idea to add the word 'only' for the benefit of users. However, the later statement about other information being optional, already implies this.

However, the later statement about other information being optional, already implies this.

I guess it should be removed.

The 'which could include your real name' sentiment (which was in the original text), appears to be quite important. If it's not important, then I agree with the removal.

However, if it is important, it appears it might be better to keep it in.

I propose to remove the whole Other information requested (which could include your real name) is optional..

You should add to your proposal that at the same time we should add the word 'only' as indicated in your comments. Adding the word 'only' partly makes up for the loss of text you propose.

KOLANICH · 2019-12-06T19:11:30Z

Policies/github-terms-of-service.md

+- If you represent a legal entity, certain information about the legal entity.
+- For [paid Accounts](#k-payment), certain information for billing purposes.
+
+Other information requested (which could include your real name) is optional.


All other information?

Yes, could be better with 'all'. However, it isn't really needed, and one school of thought might say that fewer words in this case is better. Either way, I don't think it matters much.

Either way, I don't think it matters much.

The claimed goal of your PR is to make the text shorter.

I don't think I made that the claimed goal of the PR. The rule of thumb was a general one. I wanted to say that it was a general principle that mostly applied (but not necessarily always).

If you read my PR, you'll see that I do write that one of my changes was to split one sentence into many sentences (which ultimately actually meant more words.)

Policies/github-terms-of-service.md

KOLANICH · 2019-12-06T19:14:23Z

Policies/github-terms-of-service.md

+- You must be age 13 or older. This requirement is related to our compliance with United States law. GitHub does not target our Service to children under 13, and we do not permit any Users under 13 on our Service. If we learn of any User under the age of 13, we will [terminate that User’s Account immediately](#l-cancellation-and-termination). If you are a resident of a country outside the United States, your country’s minimum age may be older; in such a case, you are responsible for complying with your country’s laws.
 - Your login may only be used by one person — i.e., a single login may not be shared by multiple people. A paid Organization  may only provide access to as many User Accounts as your subscription allows.
- You may not use GitHub in violation of export control or sanctions laws of the United States or any other applicable jurisdiction. You may not use GitHub if you are or are working on behalf of a [Specially Designated National (SDN)](https://www.treasury.gov/resource-center/sanctions/SDN-List/Pages/default.aspx) or a person subject to similar blocking or denied party prohibitions administered by a U.S. government agency.  GitHub may allow persons in certain sanctioned countries or territories to access certain GitHub services pursuant to U.S. government authorizations.  For more information, please see our [Export Controls policy](https://help.github.com/en/articles/github-and-export-controls).  
+- You may not use GitHub in violation of export control or sanctions laws of the United States or any other applicable jurisdiction. You can read the following bullet point for more information (if you don't need more information, you can just skip it):


Is you may not use repeated. Can be deduplicated.

It is repeated but I can't see how it can be de-duplicated in an effective way. The nature of the sub bullet point isn't simply a series of 'you may not' statements.

The tip given by @KOLANICH in #204 (comment) is a proper tip also for the text here.

You may not use GH for: , then a list follows.

Well, you've voiced disagreement with 'you can skip' texts, so perhaps because of that we disagree here.

If you remove the 'you can skip' device, your suggestion isn't so bad--you can do some de-duplication.

However, if the 'you can skip' device remains (in some fashion), I don't think your suggested de-duplication helps. The sub bullet point only has one 'You may not use' statement.

Collapsible-text tip has now been implemented here, in the patch as a new commit. A new PR possibly needs to be made for the commit.

KOLANICH · 2019-12-06T19:16:09Z

Policies/github-terms-of-service.md


 #### 4. User Account Security
-You are responsible for keeping your Account secure while you use our Service. We offer tools such as two-factor authentication to help you maintain your Account's security, but the content of your Account and its security are up to you.
+We offer tools (such as two-factor authentication) to help you maintain your Account's security, but you are ultimately responsible for keeping your Account (and its Content) secure while you use our Service.


you are ultimately responsible for keeping your Account (and its Content) secure while you use our Service.

Is incorrect. This wording you use means that even if the webservice authentication mechanism is hacked, the user is responsible.

You may be right but also I am inclined to think that you might be wrong too. Perhaps others can weigh-in their comments on this?

Regardless, would removing the word 'ultimately' be okay for you? If it would, I suggest that without the input of others, we just remove the word.

A little thing to consider, is that I think it's important to read what was there before, and see whether the change proposed accurately encodes what was there before.

IMHO, We offer tools (such as two-factor authentication) to help you maintain your Account's security should be also removed.

No proper opinion about removal suggested in @KOLANICH's comment #204 (comment) .

I reckon it would be a good idea to get some advice from people quite involved in the GitHub enterprise, regarding the suggested removal.

Policies/github-terms-of-service.md

KOLANICH · 2019-12-06T19:23:05Z

Policies/github-terms-of-service.md


 #### 3. Access
-GitHub employees may only access the content of your private repositories in the following situations:
+GitHub employees may only access the content of your private repositories in the following situations (if you don't care what those situations are, you can skip reading the following bullet points):


My comment #204 (comment) also applies here. If that comment doesn't sufficiently address @KOLANICH's comment, please then can @KOLANICH elaborate on exactly what is the point of contention here?

The same: I can ignore any part of ToS I want to ignore. It is obvious and the placing this obvious fact into the ToS just makes it larger and harder to review.

Policies/github-terms-of-service.md

KOLANICH · 2019-12-06T19:25:18Z

Policies/github-terms-of-service.md

 **Short version:** *You agree to these Terms of Service, plus this Section H, when using any of GitHub's APIs (Application Provider Interface), including use of the API through a third party product that accesses GitHub.*

-Abuse or excessively frequent requests to GitHub via the API may result in the temporary or permanent suspension of your Account's access to the API. GitHub, in our sole discretion, will determine abuse or excessive usage of the API. We will make a reasonable attempt to warn you via email prior to suspension.
+Use of any of GitHub's APIs requires observance of the rest of this section. So long as you don't use the API, you may just ignore the rest of this section. 


notices that I can ignore sections are just junk.

I can ignore the whole ToS and any piece in it I wanna ignore.

I am not allowed to ignore any piece of the ToS.

Hello @KOLANICH.

Slightly confused here.

Can you please elaborate on 2?

In regard to not being allowed to ignore ToS sections, sometimes in contracts (if my memory serves me right), there can be text along the lines of 'this section only applies to API users'. This is the kind of thing I wanted to encode in the 'you can skip' texts. I'd like to add that something like this already exists in the ToS, where government users are bound by extra terms and non-government users can completely ignore those extra terms. I agree that the precise phrasing of these 'you can skip' texts perhaps needs to be re-thought. The important thing (in my mind) was marking the places where such 'you can skip' devices can be placed in the ToS.

Regarding the first point, firstly, it appears to contradict your second point, so I'm a bit confused as to what you are trying to say. I've read very many contracts, including many contracts for websites and website services. My starting point for my proposed changes, was to try to make it easier for users to comply with the agreement. You can indeed ignore any piece of the ToS, but if those pieces include important user obligations, you may very badly fail in your contract compliance. What I've tried to do is highlight those parts that you can genuinely ignore without any detriment to your contract compliance.

You can indeed ignore any piece of the ToS, but if those pieces include important user obligations, you may very badly fail in your contract compliance.

Yes, but I can ignore them. I mean I can even not read them. You know, most of users when sees EULAs in sowtware installers just clicks a checkbox I have read and aggree and then next without reading. It is a lie, but it is possible to do. It is obvious that it can be done to website ToSes too. Since it is obvious there is no need to clutter the text with it: the goal of this PR is to make the ToS short in order to make it easier and faster to review and read.

Can you please elaborate on 2?

If a ToS is accepted as whole it means that a one accepting it is required to read, understand and aggree with all its parts. One must make sure that the ToS doesn't contain any conditions for example requiring a website user to pay GH a large amount of money.

P.S. I am not a lawer.

Hello @KOLANICH,

Useful to get someone else's views on these things.

I've been thinking about such things for perhaps 5-10 years now, mostly because of my adopted religious beliefs.

Firstly, yes, you are right that many users just ignore user agreements. However, I'm of the opinion that the practices of businesses and consumers need to be reformed such that there is a better respect of user agreements. My PR is part of that. I feel for other users reviewing GitHub's terms, like how I had to review them.

One point about lying -> Have thought about it a great deal, and according to my definition of lying, it isn't necessarily lying. A lie is defined (by my religion), as the telling of a falsehood with the intention to deceive. Because users can click on 'I agree' without intending to deceive (any human being), I don't think it is necessarily a lie.

Your point about trying to avoid cluttering the text is valid. Perhaps ideally, the section headings would accurately define the content of the respective sections. That way, as an example, when users came to a section labelled 'API terms', they would know that they didn't need to read the section if they weren't going to use any of the APIs. In practice though, accurate section headings can be difficult to implement. If you look at these ToS, there is a specific disclaimer saying that section headings are not legally binding. However, I'll concede that if you think this idea of accurate section headings is doable, then perhaps we should go down that route. Otherwise, I stick to believing my 'you can skip' devices, or at least some equivalent variation of them, is the right way forward.

Regarding what acceptance of a ToS means, I don't quite agree with you. I don't believe agreement to a ToS means that you have read them. I believe you can agree to the terms of an agreement without having read them. Agreement can mean that you agree to be open to penalty in accordance with the terms of an agreement. It's true that sometimes you are required to make a statement that you have read a certain ToS. I don't like such things, and I generally think they're a bit stupid. For example, in the days of AI, we will quite likely soon be able (or already are able) to get AI bots to read these contracts, at least in part. We can also enlist the help of other humans in the reading. Finally, as hinted above, I don't think you necessarily need to read agreements at all (depending upon the circumstances).

The subject of user agreements is quite a large topic. My PR is just one step in hopefully improving the current state of user agreements in general.

KOLANICH · 2019-12-07T18:35:20Z

Policies/github-terms-of-service.md

-    * A machine account is an Account set up by an individual human who accepts the Terms on behalf of the Account, provides a valid email address, and is responsible for its actions. A machine account is used exclusively for performing automated tasks. Multiple users may direct the actions of a machine account, but the owner of the Account is ultimately responsible for the machine's actions. You may maintain no more than one free machine account in addition to your free User Account.
+- You must be a human to create an Account. Accounts registered by "bots" or other automated methods are not permitted. We do permit machine accounts. When you need to deal with, or know about machine accounts, make sure you have read the following collapsible text (otherwise you can skip it):  
+<details>
+    <summary>Click to toggle showing of collapsible text.</summary>


No need to say this. Just put a summary there. You can make the block expanded by default by using open="true". If a user doesn't need its content, he can just collapse it.

Hello @KOLANICH,

The reason I felt it necessary to put such a summary (which is not a proper summary really), is for legal reasons.

We don't want legal claims against GitHub on the grounds that it wasn't clear how to read the collapsible text. Setting it to expanded by default would help, but then what if their browser software is faulty and instead renders it closed by default?

What are your thoughts about this?

KOLANICH · 2019-12-11T20:31:08Z

Policies/github-terms-of-service.md

+The different sections in this Agreement have titles and sometimes also brief summaries. Such titles and brief summaries are not legally binding. Each such summary takes the form of a collapsible text that you can expand or collapse by clicking upon the summary's heading, where the summary's heading is always the text 'Click for short version'. Each summary appears just after the relevant section title, and immediately before the relevant section body. You can completely ignore such summaries. 

 ### A. Definitions
+<details><summary open="false"><b>Click for short version</b> </summary>


Because you haven't commented on the other 'short version' contractions, I'm wondering whether you made a mistake in down-voting this change...

KOLANICH · 2019-12-11T20:31:32Z

Policies/github-terms-of-service.md


+</details>
+
+<details>


👎 I don't think putting whole sections under collapsable blocks is a good idea.

No problem with not implementing this suggested collapsible-text implementation.

Thought it might be useful because after reading definitions sections, I often just skip them except when I want clarity on a particular term.

If it's possible, can you explain why you think this is a bad idea?

I mean it makes no sense to collapse whole sections. ToS is applied as whole. Instead I suggest to summarize briefly a section and to put under a collapsible block additional details. And to make all the blocks expanded by default - if a user doesn't need them, he can collapse them with a single click.

Okay.

I don't mind about removing the collapsible block that covers the whole of the Definitions section.

I disagree with making blocks expanded by default. I don't see the point. I want to incline users to less reading, and part of that is making the blocks closed by default. I've read many user agreements, and in the vast majority of cases, for general consumers (such as might be the majority of GitHub users), the limitation on liability as well as some other sections are hardly at all important. Based on the wisdom of knowing this, and acting in the role of indirect adviser to GitHub users, I want to incline users toward not reading the detail of such things. Also, having the blocks open by default makes the whole agreement look more detailed, complicated and lengthy on first perusal. I deliberately refuse using services on occasion based on services having overly long contracts. I want to encourage potential GitHub users as much as possible into not being disheartened by the appearance of overly long and complicated terms. Blocks being closed by default is part of this.

Just a few notes about the summaries. Unfortunately, the present summaries to my mind, are a complete waste of time. The main problem with them is that they are not always accurate. Sometimes important details are missing. If you can't know whether a particular summary is accurate, you are forced into reading the whole section. It would be better to remove all the summaries, or to indicate that all the summaries are accurate along with making them accurate.

KOLANICH · 2019-12-13T13:23:28Z

I want to incline users to less reading, and part of that is making the blocks closed by default.

In fact they should be inclined into more reading.

ghost · 2019-12-13T17:10:27Z

I want to incline users to less reading, and part of that is making the blocks closed by default.

In fact they should be inclined into more reading.

Do you mean from a starting point of not reading the user agreement at all? If 'yes', then I mostly agree.

What I ultimately mean, is that users should be gently pointed in the direction of not reading things that are unlikely to be important for them. They can always override this gentle pointing, by simply expanding the related blocks.

ghost · 2020-01-08T07:26:09Z

Hello @KOLANICH,

Just read this comment. Thanks for your feedback. It's useful feedback even if I don't entirely agree with it.

Just read a bit about what "dark pattern" means. I don't consider the collapsible texts being closed by default, as being a dark pattern, at all. There's no intention whatsoever to trick users. In fact, the overall effect (IMHO), is to facilitate better comprehension of the terms. As you have already said, many users just don't bother with terms. By abbreviating them, I believe we are encouraging better study of them. I, myself, sometimes completely ignore terms when they are too long. In the UK (and probably also the EU), I also believe there is a legal basis under certain conditions, allowing me to do so. Other countries might be more strict regarding contract compliance.

More about dark patterns. If you read the paragraphs before the Definitions section properly (which is a standard thing expected of parties to contracts), then it clearly explains how to expand the collapsible texts and that apart from the collapsed summaries, the collapsible texts are legally binding. I'm open to making it clearer perhaps by using all caps or underlining. However, I don't think we should assume users will misunderstand those paragraphs because, as just stated, it is standard to expect parties to comprehend such things. If we were to, in a contrary way, assume users would misunderstand such things, then the approach to contract writing would be different. I further put forward the thought that we must assume parties will not misunderstand such straight-forward texts because otherwise the process of contract writing is just too difficult.

Anyway, to conclude, all these revisions and comments, are just ideas. I'm willing to concede on points in the final commit.

IMHO short versions should be always showed by default. Probably there is no need to encliose them at all into details tag. Only long enough irrelevant details should be enclosed. And as I have said, they probably should be also open by default since they are legally binding. If a user actively decided he doesn't need them he is free to collapse them. But anything legally binding shouldn't be hidden by default. It is a dark pattern. I have never encouraged dark patterns.

vollmera · 2020-02-18T23:19:24Z

@markfern - Thanks so much for all of your 👀 on our Terms of Service! We'll review in more detail when we have our next comment period. Any additional thoughts you have in the meantime are welcome.

philoserf

I have no authority here.

philoserf · 2020-02-24T04:59:02Z

Policies/github-terms-of-service.md

-| [A. Definitions](#a-definitions) | Some basic terms, defined in a way that will help you understand this agreement. Refer back up to this section for clarification. |
-| [B. Account Terms](#b-account-terms) | These are the basic requirements of having an Account on GitHub.  |
+| [A. Definitions](#a-definitions) | Just contains definitions. Definitions are of basic terms. Refer back up to this section for clarification on the meanings of basic terms used in the agreement. |
+| [B. Account Terms](#b-account-terms) | These are mostly the basic requirements of having an Account on GitHub. Some other things such as things about the administrative control of Accounts, are also in this section.|


Really? An adverb, mostly, in an attempt to reduce fluff and use plain English.

Hello @philoserf,

Thanks for having a look at my suggestions.

For context about the change you've highlighted, know that:

I've been making many, many changes to the terms.

I intend to make more changes.

Because of the amount of change I'm doing, I'm bound to make at least a few mistakes along the way.

These changes are simply suggestions or recommendations.

Whilst reducing 'fluff' and using plain English are worthwhile aims in this PR, they are by no means the only or perhaps even the main goals of this PR (this PR aims at making the agreement more user friendly by employing a variety of methods).

So given the above context, let's look at the highlighted change again. I can't find any specific comments I previously made about this change. However, it appears likely that the presence of subsection B1 ("Account Controls") influenced my decision in adding the word 'mostly'. The subsection doesn't appear to be about the basic requirements of having an account on GitHub even though it is in section B. Therefore, to say that the terms of section B are the basic requirements of having an Account on GitHub, appears to be inaccurate.

ghost · 2020-02-24T08:31:56Z

Hello @vollmera,

I've been making quite a few more commits to the patch used for this PR. Not sure whether this PR is linked to those additional commits. Can you tell me whether I ought to make another PR once I've finished all of my additional commits?

Thanks,

Mark

@markfern - Thanks so much for all of your 👀 on our Terms of Service! We'll review in more detail when we have our next comment period. Any additional thoughts you have in the meantime are welcome.

KOLANICH · 2020-03-27T07:47:45Z

Policies/github-terms-of-service.md

 #### 2. Survival
-&dagger; All provisions of this Agreement which, by their nature, should survive termination *will* survive termination<BR>&nbsp;&nbsp;&nbsp;&nbsp;<sup>*(including [without limitation] ownership provisions, warranty disclaimers, indemnity, and limitations of liability).*</sup>
+&dagger; All provisions of this Agreement which, by their nature, should survive termination *will* survive termination<BR><TT><sup>&nbsp;&nbsp;&nbsp;&nbsp;*(including [without limitation]:&nbsp;&nbsp;•&nbsp;ownership&nbsp;provisions,</sup></TT><BR> 
+<TT><sup>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;•&nbsp;warranty&nbsp;disclaimers,</sup></TT><BR>   


Hello @KOLANICH,

You can reject any of my suggestions. I'm not pinning my hopes on GitHub accepting any of my suggestions in particular. Also, my suggestions are part of a process of researching possible ways to rewrite contracts for making them more user friendly; in line with this, it's perfectly acceptable to reject my suggestions.

Having a look at what you have highlighted, I haven't as such—as far as I can tell—modified the sentence. Instead, I've tried to modify the previous visual formatting of the sentence, by use of indentation and carriage returns (a bit like code pretty printers), to try to make it easier to comprehend. Upon closer inspection, it appears you've highlighted an out-of-date modification (where I possibly used an incorrect, or 'not so good' encoding method). The new version should be as displayed at the bottom of this comment.

Once again, you can reject any of my suggestions.

&dagger; All provisions of this Agreement which, by their nature, should survive termination *will* survive termination         *(including [without limitation]:                         • ownership provisions,                         • warranty disclaimers,                         • indemnity,    AND                         • limitations of liability).*

2. Survival

† All provisions of this Agreement which, by their nature, should survive termination will survive termination
^{(including [without limitation]:}
^{• ownership provisions,}
^{• warranty disclaimers,}
^{• indemnity, AND}
^{• limitations of liability).}

ghost

I don’t help me

ghost · 2020-04-20T09:49:46Z

Policies/github-terms-of-service.md

       such that all the space in the width is used --> 
-  <TR><TD ALIGN="RIGHT" WIDTH="1%">
+  <TR><TD ALIGN="RIGHT" WIDTH="1%" COLSPAN="2">
 represent the complete and exclusive statement of the agreement between you and us.


Suggested change

represent the complete and exclusive statement of the agreement between you and us.

represent the complete and exclusive statement of the agreement between you and us.

Hello @Lovegill5, thanks for approving this pull request.

Slightly confused about your suggested changes because they don't seem to do anything. Are they mistakes?

BTW, I've made further changes since the last PR snapshot, and plan to make even more changes. Going through an extensive drafting process.

Thanks.

ghost · 2020-04-20T09:52:40Z

Policies/github-terms-of-service.md

 <TABLE>
  <TR><TD ALIGN="LEFT">
-&dagger; These Terms of Service, together with the GitHub Privacy Statement,
+&dagger;&nbsp;These&nbsp;Terms&nbsp;of&nbsp;Service,&nbsp;together&nbsp;with&nbsp;the&nbsp;GitHub&nbsp;Privacy&nbsp;Statement,


Suggested change

&dagger; These Terms of Service, together with the GitHub Privacy Statement,

&dagger; These Terms of Service, together with the GitHub Privacy Statement,

ghost

I m ready

ghost

I m ready to agreement follow rules

ghost · 2020-04-23T05:46:09Z

Policies/github-terms-of-service.md

 ## G. Intellectual Property Notice
  </TD>
  <TD ALIGN="CENTER" VALIGN="MIDDLE">
 ©®™


Suggested change

©®™

©®™

insanm61 · 2020-06-06T20:57:39Z

Itry

- §"Section titles and summaries". - the different section summaries.

Slight improvement.

ghost

*A Policies/github-terms-of-service.md

Viewed

@@ -77,69 +77,72 @@

^{^_{_🔱}}
^{^_{_🔱}} In all other cases, In all other cases,

ghost · 2020-07-10T12:29:30Z

I need your help sir I want my account delete

Previously described as one-row, two-cell tables, the devices are now called conditional-text devices which appears to be more apt. A graphic has been developed to tag the table used in the device, thereby making it clearer that each such table constitutes the conditional-text device. The right-most cell content has been moved one line down (using a simple line break), which I believe makes processing/reading the device visually clearer. Previously, if conventional material was better presented as a one-row, two-cell table, an added artificial empty row had to be added so that the table would not be interpreted as being this device. By using a graphic instead to tag such tables, such artificial empty rows are no longer needed. Hence, they have now been removed.

KOLANICH · 2020-10-01T20:50:26Z

Policies/github-terms-of-service.md

+#### Conditional-text devices
+  <table>
+  <tr><td valign="top"><sup><sup><sub><sub><sub>🔱</sub></sub></sub></sup></sup> For each<br> 
+        &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<i>one&#8209;row,&nbsp;three&#8209;cell</i>&nbsp;table<br>


Could you not to use unprintable characters for alignment?

Hello @KOLANICH, not precisely sure to what you are referring, but I think you might be referring to the use of tables where the borders of the tables are displayed.

The typography and visualisations are very much in-development, new, and untested. The more I've worked on these terms and conditions, the more I've developed new visualisations. In respect of the table, I think that was probably the only way I thought was possible for the kind of alignment I wanted. If I had known of another way where the alignment didn't involve displaying extra things, then I would have gone for it.

Looking at what you have highlighted, I probably wanted to split the relatively long sentence, into three visually-separate chunks, for the facilitating of easier and quicker comprehension. For that, it seems that I chose to use a three-cell, single-row table, with each cell containing a different part of the sentence.

Am planning on returning to this work soon. Want to complete the work now. Plan then to use it as an example to others exampling the ways in which the present state of online terms and conditions can be much improved.

Thanks.

pcihon · 2020-10-15T21:44:38Z

👋 @markfern - 🙇‍♀️ again for opening this PR!

We'll review in more detail when we have our next comment period. Any additional thoughts you have in the meantime are welcome.

That time is now! Thanks for your continued patience and work on this PR in the meantime.

Can you tell me whether I ought to make another PR once I've finished all of my additional commits?

It looks like a lot of the changes are cosmetic (emojis, collapsible sections), rather than substantive. It would be helpful to see just the substantive changes all in one PR. Given all of the comments and commits in this PR, we'd ask that you open a new PR with just those changes. If it is at all unclear, please let us know! 🙇‍♀️

/cc @vollmera

ghost · 2020-10-19T06:59:48Z

👋 @markfern - 🙇‍♀️ again for opening this PR!

We'll review in more detail when we have our next comment period. Any additional thoughts you have in the meantime are welcome.

That time is now! Thanks for your continued patience and work on this PR in the meantime.

It looks like a lot of the changes are cosmetic (emojis, collapsible sections), rather than substantive. It would be helpful to see just the substantive changes all in one PR. Given all of the comments and commits in this PR, we'd ask that you open a new PR with just those changes. If it is at all unclear, please let us know! 🙇‍♀️

@pcihon: thanks for considering this PR. Most of the changes are likely cosmetic. Wasn't particularly looking at changing the substance; I do not have any specialist legal skills. Instead, the changes were more along the lines of usability and readability. Am slightly caught up in some other things at the moment, but hope to return to this soon.

The terms and conditions being in the public domain, will hopefully mean that the wider community will also be able to benefit from any improvements in these terms.

Thanks.

Mrlove5 · 2023-11-06T23:59:42Z

@markfern i hope I message right place Yeah I m ready sir can u give me full details how he working how to earn money and license what kind I seriously don't know i 2020 github account I created everything buy mistake and today I know after my account lovegill5! Third party authority organisation I don't who control please help me if any job have you I will doing I waiting sir your reply

Mrlove5 · 2023-11-07T00:34:16Z

Please contact me if you disagree with any of my changes or you are unsure about any of them.

I use the general rule of thumb that less is better.

No need to say things like 'thank you'. If you want to say 'thank you', say it on your home page. People have little time, and want to spend as little time as possible reading user agreements such as this one.

Sometimes I've changed the ordering of statements because it makes for easier comprehension.

Sometimes I've just taken text out that is unnecessary.

I've tried to make changes so that for the vast majority of your users, it is quicker to get through them. Eg. majority of users probably don't use the APIs, so I've changed the terms so that you aren't forced to read the terms relating to the APIs if it is not relevant to you.

On the face of it, it may seem better to inform users about everything so that they are fully informed. However, in reality, users (especially ones not representing organisations), find it hard to mentally keep in mind all of the details of a user agreement. This means that informing them about everything can actually mean that they are less aware rather than more aware. If you try to be more selective with what you communicate, they can end-up being in fact more informed because they find the communication less unwieldy.

Using bullet points can make for better comprehension because it is generally a better visual organisation of information.

Sometimes, I've moved text so that a 'you can skip the rest of this section' statement can be made. So what happens, is that you read important stuff at the top (text sometimes moved to the top), and then you hit such a skipping statement so that you can skip the rest of the section.

Sometimes sentences have been combined to say the same thing with less words, in hopefully a clearer way. On the other hand, at least in one place I've split a very long-winded sentence into a few sentences, to make for easier comprehension. You find such very long-winded sentences in legal contracts. Even though they may be legally sound, they are generally very difficult to read.

Most of the changes should be easy to understand.

Further Advice

==============

You can:

look at the advice I gave to Microsoft regarding one of their terms and conditions documents, that can be accessed by going to: https://answers.microsoft.com/en-us/skype/forum/all/processing-the-microsoft-services-agreement-legal/e104804e-c2c0-413f-b8e5-180a2b029415 .

look at how the BBC website terms and conditions (https://www.bbc.co.uk/usingthebbc/terms/) are arranged, and try to draw inspiration from them, in order to simplify the presentation, and improve the accessibility of, your terms.
@markfern hope I message right place Yeah I m ready sir can u give me full details how he working how to earn money and license what kind I seriously don't know i 2020 github account I created everything buy mistake and today I know after my account lovegill5! Third party authority organisation I don't who control please help me if any job have you I will doing everything yeah help me I m alright so much late I waiting sir your reply

Mrlove5 · 2024-10-05T13:39:48Z

Please contact me if you disagree with any of my changes or you are unsure about any of them.

I use the general rule of thumb that less is better.

No need to say things like 'thank you'. If you want to say 'thank you', say it on your home page. People have little time, and want to spend as little time as possible reading user agreements such as this one.

Sometimes I've changed the ordering of statements because it makes for easier comprehension.

Sometimes I've just taken text out that is unnecessary.

I've tried to make changes so that for the vast majority of your users, it is quicker to get through them. Eg. majority of users probably don't use the APIs, so I've changed the terms so that you aren't forced to read the terms relating to the APIs if it is not relevant to you.

On the face of it, it may seem better to inform users about everything so that they are fully informed. However, in reality, users (especially ones not representing organisations), find it hard to mentally keep in mind all of the details of a user agreement. This means that informing them about everything can actually mean that they are less aware rather than more aware. If you try to be more selective with what you communicate, they can end-up being in fact more informed because they find the communication less unwieldy.

Using bullet points can make for better comprehension because it is generally a better visual organisation of information.

Sometimes, I've moved text so that a 'you can skip the rest of this section' statement can be made. So what happens, is that you read important stuff at the top (text sometimes moved to the top), and then you hit such a skipping statement so that you can skip the rest of the section.

Sometimes sentences have been combined to say the same thing with less words, in hopefully a clearer way. On the other hand, at least in one place I've split a very long-winded sentence into a few sentences, to make for easier comprehension. You find such very long-winded sentences in legal contracts. Even though they may be legally sound, they are generally very difficult to read.

Most of the changes should be easy to understand.

Further Advice

You can:

look at the advice I gave to Microsoft regarding one of their terms and conditions documents, that can be accessed by going to: https://answers.microsoft.com/en-us/skype/forum/all/processing-the-microsoft-services-agreement-legal/e104804e-c2c0-413f-b8e5-180a2b029415 .

look at how the BBC website terms and conditions (https://www.bbc.co.uk/usingthebbc/terms/) are arranged, and try to draw inspiration from them, in order to simplify the presentation, and improve the accessibility of, your terms.

This one my old project vision how to I get nack

Mrlove5 · 2024-10-16T11:57:14Z

Please contact me if you disagree with any of my changes or you are unsure about any of them.

I use the general rule of thumb that less is better.

No need to say things like 'thank you'. If you want to say 'thank you', say it on your home page. People have little time, and want to spend as little time as possible reading user agreements such as this one.

Sometimes I've changed the ordering of statements because it makes for easier comprehension.

Sometimes I've just taken text out that is unnecessary.

I've tried to make changes so that for the vast majority of your users, it is quicker to get through them. Eg. majority of users probably don't use the APIs, so I've changed the terms so that you aren't forced to read the terms relating to the APIs if it is not relevant to you.

On the face of it, it may seem better to inform users about everything so that they are fully informed. However, in reality, users (especially ones not representing organisations), find it hard to mentally keep in mind all of the details of a user agreement. This means that informing them about everything can actually mean that they are less aware rather than more aware. If you try to be more selective with what you communicate, they can end-up being in fact more informed because they find the communication less unwieldy.

Using bullet points can make for better comprehension because it is generally a better visual organisation of information.

Sometimes, I've moved text so that a 'you can skip the rest of this section' statement can be made. So what happens, is that you read important stuff at the top (text sometimes moved to the top), and then you hit such a skipping statement so that you can skip the rest of the section.

Sometimes sentences have been combined to say the same thing with less words, in hopefully a clearer way. On the other hand, at least in one place I've split a very long-winded sentence into a few sentences, to make for easier comprehension. You find such very long-winded sentences in legal contracts. Even though they may be legally sound, they are generally very difficult to read.

Most of the changes should be easy to understand.

Further Advice

==============

You can:

look at the advice I gave to Microsoft regarding one of their terms and conditions documents, that can be accessed by going to: https://answers.microsoft.com/en-us/skype/forum/all/processing-the-microsoft-services-agreement-legal/e104804e-c2c0-413f-b8e5-180a2b029415 .

look at how the BBC website terms and conditions (https://www.bbc.co.uk/usingthebbc/terms/) are arranged, and try to draw inspiration from them, in order to simplify the presentation, and improve the accessibility of, your terms.

How long I waiting sir

KOLANICH reviewed Dec 6, 2019

View reviewed changes

Policies/github-terms-of-service.md Outdated Show resolved Hide resolved

KOLANICH reviewed Dec 6, 2019

View reviewed changes

Policies/github-terms-of-service.md Outdated Show resolved Hide resolved

KOLANICH reviewed Dec 6, 2019

View reviewed changes

Policies/github-terms-of-service.md Outdated Show resolved Hide resolved

This comment has been minimized.

Sign in to view

KOLANICH reviewed Dec 6, 2019

View reviewed changes

Policies/github-terms-of-service.md Outdated Show resolved Hide resolved

KOLANICH reviewed Dec 6, 2019

View reviewed changes

Policies/github-terms-of-service.md Outdated Show resolved Hide resolved

KOLANICH reviewed Dec 6, 2019

View reviewed changes

Policies/github-terms-of-service.md Outdated Show resolved Hide resolved

KOLANICH reviewed Dec 6, 2019

View reviewed changes

KOLANICH reviewed Dec 7, 2019

View reviewed changes

KOLANICH reviewed Dec 11, 2019

View reviewed changes

philoserf suggested changes Feb 24, 2020

View reviewed changes

KOLANICH reviewed Mar 27, 2020

View reviewed changes

ghost approved these changes Apr 20, 2020

View reviewed changes

ghost approved these changes Apr 21, 2020

View reviewed changes

ghost reviewed Apr 23, 2020

View reviewed changes

MarkFern added 2 commits May 5, 2020 08:11

Delete coffee-in-cup; yellow 2; small.png

7d9be5c

Delete coffee-in-cup; yellow green; small.png

e56a619

MarkFern added 5 commits June 8, 2020 07:59

Section links corrected

0523c7a

📈 Formatting of "‘:collapsible:’ texts" section

dcc6634

2 small formatting improvements

f162e77

📈 formatting re. section titles & summaries

8f02d2c

- §"Section titles and summaries". - the different section summaries.

Formatting 📈 to §"Section titles and summaries"

429f97d

Slight improvement.

ghost reviewed Jun 12, 2020

View reviewed changes

Chainarong24NutDogg mentioned this pull request Jun 13, 2020

[]() #250

Closed

MarkFern added 5 commits June 17, 2020 06:25

📈 to §"Tridented texts"; just a few small changes

07c0a3d

Add files via upload

daef768

Add files via upload

6a0a538

Delete GitHub Ts&Cs conditional-device graphic.png

7062eab

Add files via upload

7274e3b

AiezMansor approved these changes Sep 24, 2020

View reviewed changes

Mvaxtuan16V approved these changes Oct 1, 2020

View reviewed changes

KOLANICH reviewed Oct 1, 2020

View reviewed changes

Mvaxtuan16V approved these changes Oct 2, 2020

View reviewed changes

Base automatically changed from master to main October 14, 2020 22:32

pcihon closed this Oct 15, 2020

	represent the complete and exclusive statement of the agreement between you and us.
	represent the complete and exclusive statement of the agreement between you and us.

	&dagger; These Terms of Service, together with the GitHub Privacy Statement,
	&dagger; These Terms of Service, together with the GitHub Privacy Statement,


		</details>

		<details>

Mark Fernandes's improvements to the main GitHub terms and conditions #204

Mark Fernandes's improvements to the main GitHub terms and conditions #204

Uh oh!

Conversation

ghost commented Dec 6, 2019

Further Advice

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

KOLANICH Dec 7, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

KOLANICH Dec 6, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

This comment has been minimized.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

KOLANICH Dec 7, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

KOLANICH Dec 6, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

KOLANICH Dec 7, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ghost Dec 7, 2019 • edited by ghost Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

KOLANICH Dec 7, 2019 •

edited

Loading

KOLANICH Dec 6, 2019 •

edited

Loading

KOLANICH Dec 7, 2019 •

edited

Loading

KOLANICH Dec 6, 2019 •

edited

Loading

KOLANICH Dec 7, 2019 •

edited

Loading

ghost Dec 7, 2019 •

edited by ghost

Loading

ghost Dec 12, 2019 •

edited by ghost

Loading

KOLANICH Dec 11, 2019 •

edited

Loading

KOLANICH Dec 12, 2019 •

edited

Loading