/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
Our Style Guide
This document is automated so we can show examples. Click "Document" above to read as normal text.
  1. Agreement frame
    Agreements can be formatted as [G/Agt-Form-CmA/US/Frame/2Parties/0.md]. If in English and two parties, you are done. If more, or in another language then point at one of the variants. If it is not an agreement (deed, permit, etc.) use the basic section format described below. Or ask us for guidance.
  2. Sections
    Organize the text of a document as a list of its sections.
    1. If a section has subsections, make the section as a list of its subsections.
    2. Rinse and repeat as deep as your subsections go.
    3. Section headings are in bold, on a separate line from the body of the text.
    All this is done easily (tools, not rules) if you use components like [G/Z/ol/s3].
  3. Defined Terms
    Defined terms should be presented in green. You can do this by {curly bracketing} the defined term in your text. We prefer that each defined term start with an underscore, for consistency and for a technical reason we can explain elsewhere. E.g. {_Company} and {_Intellectual_Property}. The leading underline is preferred practice to make immediately clear that it is intended as a defined term and easier to spot in reviewing and searches. We have a default list of defined terms that is part of the forms: [G/Agt-Form-CmA/US/Def/Link/0.md]. Using them improves consistency, makes them green and turns defined terms into hyperlinks to the definitions. That helps us read.
  4. Definitions
    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:
    • Def.Defined_Term.sec="{_Defined_Term}" means ....
    • There is no need for "shall mean" or "means herein," etc.
  5. Section Organization
    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:
    1. 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.
    2. 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 ... '
    3. 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. Data, Deal Points
    Where a document needs data, such as a party name or address, price, date, etc., please use one of our standard formats. We generally prefer a format like {Product1.Weight}. (This is likely to be driven by systems of automation, e.g. blockchain. Let's see if we can get on the same page there, too.) If the party is us or any of the persons in the list G/U/Who/, please use Px.=[G/U/Who/person_name]. If not, please make a file for the person in that format.
  7. Version naming
    Versioning is a vast subject, handled on a number of different levels. Additional solutions will be found, but the basics are simple.
    1. "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.
    2. 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.
    3. 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. Editorial Choices
    This is the beginning of a list of editorial preferences:
    1. 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.
    2. "The Buyer" versus "Buyer". ....
    3. etc.
  9. Collaboration
    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.