/Docs/S/OurLegal/Sec/StyleSheet_v0.md
Source views: Source JSON(ish) on GitHub (VSCode) Doc views: Document (&k=r00t): Visual Print Technical: OpenParameters Xray
{- "edges" : [
- [ "1.sec" : "G/Agt-Form-CmA/US/Frame/2Parties/0.md" ] , [ "2.00.sec" : "G/Z/ol/s3" ] , [ "2." : "G/Z/ol/s3" ] , [ "3.sec" : "G/Agt-Form-CmA/US/Def/Link/0.md" ] , [ "4." : "G/Z/ol-bullet/s2" ] , [ "5." : "G/Z/ol/s3" ] , [ "6.sec" : "G/U/Who/person_name" ] , [ "7." : "G/Z/ol/s3" ] , [ "8." : "G/Z/ol/s3" ] , [ "" : "G/Z/ol/9" ] ,
]
"data" {- "Ti" : "Our Style Guide" ,
"0.sec" : "This document is automated so we can show examples. Click \"Document\" above to read as normal text." ,
"1.Ti" : "Agreement frame" ,
"2.Ti" : "Sections" ,
"2.0.sec" : "Organize the text of a document as a list of its sections." ,
"2.1.sec" : "If a section has subsections, make the section as a list of its subsections." ,
"2.2.sec" : "Rinse and repeat as deep as your subsections go." ,
"2.3.sec" : "Section headings are in bold, on a separate line from the body of the text." ,
"Note1" : "\"s3\" means \"s\"ection bodies w/o headings, \"3\" of them. If you dropped the \"s\" it would expect 2.1.Ti=... etc. and if you did \"4\" it would expect 2.4.sec=... " ,
"3.Ti" : "Defined Terms" ,
"4.Ti" : "Definitions" ,
"4.0.sec" : "The definitions themselves should be in a separate section, with a heading \"Definitions\" and a list of the defined terms. The list should be mostly alphabetical. We prefer definitions in the singular - e.g. \"SoW\", not \"SoWs\". (The \"Construction\" section handles issues of plural, gender, etc.) Defined terms should be structured as:" ,
"4.1.sec" : "Def.Defined_Term.sec=\"", "_Defined_Term", "\" means ...." ,
"4.2.sec" : "There is no need for \"shall mean\" or \"means herein,\" etc." ,
"5.Ti" : "Section Organization" ,
"5.0.sec" : "It would greatly help our review if sections are organized along patterns that we are used to. If you can't find a form agreement from a library to serve as a model, please try to conform to the following to the extent practical:" ,
"5.1.sec" : "The first section should be a \"Focus\" section. It will include a subsection of \"Variables\" and the sections that define the basic deal. It should be possible for a person to understand the basic elements of the transaction after reading only the \"Focus\" section. " ,
"5.2.sec" : "The \"Variables\" subsection defines items such as prices, dates, descriptions, special provisions. These are handled like defined terms. E.g., define ' \"", "_Price_Per_Unit", "\" means 8 Euros.' And in the document use ' A discount of ", "_Discount_Rate", " will be applied to the ", "_Price_Per_Unit", " for purchases of more than ... '" ,
"5.3.sec" : "After the \"Focus\" section, the other sections can be organized as \"Relationship\", \"Miscellaneous\" and \"Interpretation.\" This is not mandatory, but allows us to find things rapidly. For many documents, \"Relationship\" is the largest of these sections. It includes issues such as IP, Confidentiality, Representations, continuing Covenants, Disputes, etc. \"Miscellaneous\" is most about the agreement itself. \"Interpretation\" has two subsections: \"Definitions\" and \"Construction.\" Definitions has been discussed above. These definitions are intended to be anodyne, background, deepening. They are not intended to contain surprises. If a term is used in a surprising way, it is more appropriate to put it in the \"Variables\" section. The general principle of \"increasing banality\" applies. " ,
"6.Ti" : "Data, Deal Points" ,
"7.Ti" : "Version naming" ,
"7.0.sec" : "Versioning is a vast subject, handled on a number of different levels. Additional solutions will be found, but the basics are simple." ,
"7.1.sec" : "\"Git\" provides a comprehensive, ever-present, general-purpose, nearly fool-proof platform for versioning. It provides a unique cryptographic key for each \"state\" of the materials. That eliminates most doubt and arguments about what was said, when, by whom. We will use it and suggest that you do, too. We will rely to the extent available on git repos curated by the WorldCC and other neutral organizations to further avoid doubt and demonstrate our intent to have a constructive relationship with you." ,
"7.2.sec" : "Among those materials, the \"current\" version is \"0.md\". Currently, of course means that it can change. Static versions can be made in the format 01.md, 02.md. Those are represented by the host to be static and not to change. git provides a way to verify whether true. So we suggest that in our negotiations, that we exchange drafts as \"0.md\" and if either of us wants to save-out a version that we copy the (then current) 0.md as a new xx.md. 01.md works, but we could also do 2017-09-14a.md, etc. as lawyers sometimes do. " ,
"7.3.sec" : "Blockchains and IPFS (ipfs.io) provide more comprehensive solutions, as do contract management software applications. Our focus here is on the document standards, but this blends with actual transacting, which should be on whatever platform the parties want." ,
"8.Ti" : "Editorial Choices" ,
"8.0.sec" : "This is the beginning of a list of editorial preferences:" ,
"8.1.sec" : "We eschew the \"Oxford comma.\" We understand and respect the reasons for it, but note that it is rare outside of legal writing, heavy", "q", " and not used in languages other than English. We think the structural ambiguities that it resolves can be resolved using better writing or formatting as lists. In many of the core materials we provide for Oxford commas as above. But our preference is that these be zero-ed out in the document view." ,
"8.2.sec" : "\"The Buyer\" versus \"Buyer\". ...." ,
"8.3.sec" : "etc." ,
"9.Ti" : "Collaboration" ,
"9.sec" : "You can send us your work by any means, including even pasting in an email. If you want to really make it easy (for us), get a GitHub account, fork the repository, make your additions and do a \"pull request.\" For those who know nothing about any of this, it might take you an hour to acquire basic competence. " ,
}
}