Re: BUS: [Promotor] Administrative Regulations [attn. Rulekeepor]
On Fri, Sep 4, 2020 at 12:02 AM Aris Merchant via agora-business wrote: > > I intend, for each of the two "---" delimited texts below, to > promulgate that text as an Administrative Regulation of the office of > Promotor with 1.5 Agoran consent. For each intent, with 1.5 Agoran consent, I do so. -Aris > --- > Certification > > For the Promotor to cause a proposal to become pending with 2+N support, > where N is equal to the number of times e has done so in the past 7 days, > is for em to certify it. > > A proposal is certifiable if: > 1. it is reasonably narrowly tailored to fix one or more problems, > including a) bugs, b) errors, c) ambiguities, and d) vulnerabilities*; or > 2. unusual or exigent circumstance render it in the public interest for >it to become pending via this method. > > * Note: Any of these problems may arise from a single source or the > interaction > of multiple sources, which may be individually unproblematic. This provision > is to be interpreted broadly and flexibly to effectuate its spirit. > > The Promotor SHOULD NOT certify a non-certifiable proposal. Players SHOULD > support an intent to certify a proposal if and only if it is certifiable. > > The author of a proposal in the pool CAN, by announcement, request > certification of the proposal, provided e does so in a message that has either > "Promotor" or "Proposal" in the subject line; e SHOULD NOT do so unless > e believes eir proposal is certifiable and is ENCOURAGED to explain why > eir proposal is certifiable. Once certification is requested, the Promotor > SHALL respond publicly before publishing the next report that contains > the proposal, unless the proposal is withdrawn or pended in the interim. > Petitioning the Promotor to certify a proposal is DEPRECATED. > > --- > Proposal Style Guide > > Players SHOULD format proposals in accordance with the following guidelines. > These guidelines represent the Promotor's preferred formatting. Most of > these guidelines are flexible recommendations, but where something is marked > as > STRONGLY DISCOURAGED, doing it is actively inconvenient for the Promotor. > > I. Headers and Metadata. > > 1. Format headers as close as possible to the heading used for distributions, >which looks like this: > > Title: _ > Adoption index: _._ > Author: > Co-authors: , > > To be clear: > a) write the fields in that order; > b) write out all the fields, even the ones that have default values; and > c) write each field on its own line. > > 2. a) Give proposals titles 35 characters or less. >b) Giving proposals titles over 70 characters is STRONGLY DISCOURAGED. > > II. Bodies. > > 1. Indent Proposals two spaces per indent level. > > 2. a) Wrap proposal lines to 80 characters or less. >b) Making it so the Promotor cannot wrap lines to 80 characters or less is > STRONGLY DISCOURAGED unless it is absolutely unavoidable (e.g. > in the case of URLs). > > 3. Players are STRONGLY DISCOURAGED from placing markings that indicate the >start of the proposal's text on the same line as the start of the text. > ---
Re: BUS: [Promotor] Administrative Regulations
On 9/4/20 1:01 AM, Aris Merchant via agora-business wrote: I intend, for each of the two "---" delimited texts below, to promulgate that text as an Administrative Regulation of the office of Promotor with 1.5 Agoran consent. --- Certification For the Promotor to cause a proposal to become pending with 2+N support, where N is equal to the number of times e has done so in the past 7 days, is for em to certify it. A proposal is certifiable if: 1. it is reasonably narrowly tailored to fix one or more problems, including a) bugs, b) errors, c) ambiguities, and d) vulnerabilities*; or 2. unusual or exigent circumstance render it in the public interest for it to become pending via this method. * Note: Any of these problems may arise from a single source or the interaction of multiple sources, which may be individually unproblematic. This provision is to be interpreted broadly and flexibly to effectuate its spirit. The Promotor SHOULD NOT certify a non-certifiable proposal. Players SHOULD support an intent to certify a proposal if and only if it is certifiable. The author of a proposal in the pool CAN, by announcement, request certification of the proposal, provided e does so in a message that has either "Promotor" or "Proposal" in the subject line; e SHOULD NOT do so unless e believes eir proposal is certifiable and is ENCOURAGED to explain why eir proposal is certifiable. Once certification is requested, the Promotor SHALL respond publicly before publishing the next report that contains the proposal, unless the proposal is withdrawn or pended in the interim. Petitioning the Promotor to certify a proposal is DEPRECATED. --- Proposal Style Guide Players SHOULD format proposals in accordance with the following guidelines. These guidelines represent the Promotor's preferred formatting. Most of these guidelines are flexible recommendations, but where something is marked as STRONGLY DISCOURAGED, doing it is actively inconvenient for the Promotor. I. Headers and Metadata. 1. Format headers as close as possible to the heading used for distributions, which looks like this: Title: _ Adoption index: _._ Author: Co-authors: , To be clear: a) write the fields in that order; b) write out all the fields, even the ones that have default values; and c) write each field on its own line. 2. a) Give proposals titles 35 characters or less. b) Giving proposals titles over 70 characters is STRONGLY DISCOURAGED. II. Bodies. 1. Indent Proposals two spaces per indent level. 2. a) Wrap proposal lines to 80 characters or less. b) Making it so the Promotor cannot wrap lines to 80 characters or less is STRONGLY DISCOURAGED unless it is absolutely unavoidable (e.g. in the case of URLs). 3. Players are STRONGLY DISCOURAGED from placing markings that indicate the start of the proposal's text on the same line as the start of the text. --- I support both intents. Sorry for my absence from the lists; I'm going through the backlog now. -- Trigon I’m always happy to become a party to contracts. I LOVE SPAGHETTI transfer Jason one coin nch was here I hereby don't... trust... the dragon... don't... trust... the dragon... Do not Construe Jason's message with subject TRIGON as extending this
Re: BUS: [Promotor] Administrative Regulations
On 2020-09-04 07:01, Aris Merchant via agora-business wrote: > I intend, for each of the two "---" delimited texts below, to > promulgate that text as an Administrative Regulation of the office of > Promotor with 1.5 Agoran consent. I support the intent for the Proposal Style Guide. I object to the intent for Certification. > --- > Certification > > For the Promotor to cause a proposal to become pending with 2+N support, > where N is equal to the number of times e has done so in the past 7 days, > is for em to certify it. > > A proposal is certifiable if: > 1. it is reasonably narrowly tailored to fix one or more problems, > including a) bugs, b) errors, c) ambiguities, and d) vulnerabilities*; or > 2. unusual or exigent circumstance render it in the public interest for >it to become pending via this method. > > * Note: Any of these problems may arise from a single source or the > interaction > of multiple sources, which may be individually unproblematic. This provision > is to be interpreted broadly and flexibly to effectuate its spirit. > > The Promotor SHOULD NOT certify a non-certifiable proposal. Players SHOULD > support an intent to certify a proposal if and only if it is certifiable. > > The author of a proposal in the pool CAN, by announcement, request > certification of the proposal, provided e does so in a message that has either > "Promotor" or "Proposal" in the subject line; e SHOULD NOT do so unless > e believes eir proposal is certifiable and is ENCOURAGED to explain why > eir proposal is certifiable. Once certification is requested, the Promotor > SHALL respond publicly before publishing the next report that contains > the proposal, unless the proposal is withdrawn or pended in the interim. > Petitioning the Promotor to certify a proposal is DEPRECATED. > > --- > Proposal Style Guide > > Players SHOULD format proposals in accordance with the following guidelines. > These guidelines represent the Promotor's preferred formatting. Most of > these guidelines are flexible recommendations, but where something is marked > as > STRONGLY DISCOURAGED, doing it is actively inconvenient for the Promotor. > > I. Headers and Metadata. > > 1. Format headers as close as possible to the heading used for distributions, >which looks like this: > > Title: _ > Adoption index: _._ > Author: > Co-authors: , > > To be clear: > a) write the fields in that order; > b) write out all the fields, even the ones that have default values; and > c) write each field on its own line. > > 2. a) Give proposals titles 35 characters or less. >b) Giving proposals titles over 70 characters is STRONGLY DISCOURAGED. > > II. Bodies. > > 1. Indent Proposals two spaces per indent level. > > 2. a) Wrap proposal lines to 80 characters or less. >b) Making it so the Promotor cannot wrap lines to 80 characters or less is > STRONGLY DISCOURAGED unless it is absolutely unavoidable (e.g. > in the case of URLs). > > 3. Players are STRONGLY DISCOURAGED from placing markings that indicate the >start of the proposal's text on the same line as the start of the text. > --- -- Falsifian
Re: BUS: [Promotor] Administrative Regulations
I support both such intents. On 9/4/2020 3:01 AM, Aris Merchant via agora-business wrote: I intend, for each of the two "---" delimited texts below, to promulgate that text as an Administrative Regulation of the office of Promotor with 1.5 Agoran consent. --- Certification For the Promotor to cause a proposal to become pending with 2+N support, where N is equal to the number of times e has done so in the past 7 days, is for em to certify it. A proposal is certifiable if: 1. it is reasonably narrowly tailored to fix one or more problems, including a) bugs, b) errors, c) ambiguities, and d) vulnerabilities*; or 2. unusual or exigent circumstance render it in the public interest for it to become pending via this method. * Note: Any of these problems may arise from a single source or the interaction of multiple sources, which may be individually unproblematic. This provision is to be interpreted broadly and flexibly to effectuate its spirit. The Promotor SHOULD NOT certify a non-certifiable proposal. Players SHOULD support an intent to certify a proposal if and only if it is certifiable. The author of a proposal in the pool CAN, by announcement, request certification of the proposal, provided e does so in a message that has either "Promotor" or "Proposal" in the subject line; e SHOULD NOT do so unless e believes eir proposal is certifiable and is ENCOURAGED to explain why eir proposal is certifiable. Once certification is requested, the Promotor SHALL respond publicly before publishing the next report that contains the proposal, unless the proposal is withdrawn or pended in the interim. Petitioning the Promotor to certify a proposal is DEPRECATED. --- Proposal Style Guide Players SHOULD format proposals in accordance with the following guidelines. These guidelines represent the Promotor's preferred formatting. Most of these guidelines are flexible recommendations, but where something is marked as STRONGLY DISCOURAGED, doing it is actively inconvenient for the Promotor. I. Headers and Metadata. 1. Format headers as close as possible to the heading used for distributions, which looks like this: Title: _ Adoption index: _._ Author: Co-authors: , To be clear: a) write the fields in that order; b) write out all the fields, even the ones that have default values; and c) write each field on its own line. 2. a) Give proposals titles 35 characters or less. b) Giving proposals titles over 70 characters is STRONGLY DISCOURAGED. II. Bodies. 1. Indent Proposals two spaces per indent level. 2. a) Wrap proposal lines to 80 characters or less. b) Making it so the Promotor cannot wrap lines to 80 characters or less is STRONGLY DISCOURAGED unless it is absolutely unavoidable (e.g. in the case of URLs). 3. Players are STRONGLY DISCOURAGED from placing markings that indicate the start of the proposal's text on the same line as the start of the text. --- -- ATMunn friendly neighborhood notary and Speaker of Agora :)
BUS: [Promotor] Administrative Regulations
I intend, for each of the two "---" delimited texts below, to promulgate that text as an Administrative Regulation of the office of Promotor with 1.5 Agoran consent. --- Certification For the Promotor to cause a proposal to become pending with 2+N support, where N is equal to the number of times e has done so in the past 7 days, is for em to certify it. A proposal is certifiable if: 1. it is reasonably narrowly tailored to fix one or more problems, including a) bugs, b) errors, c) ambiguities, and d) vulnerabilities*; or 2. unusual or exigent circumstance render it in the public interest for it to become pending via this method. * Note: Any of these problems may arise from a single source or the interaction of multiple sources, which may be individually unproblematic. This provision is to be interpreted broadly and flexibly to effectuate its spirit. The Promotor SHOULD NOT certify a non-certifiable proposal. Players SHOULD support an intent to certify a proposal if and only if it is certifiable. The author of a proposal in the pool CAN, by announcement, request certification of the proposal, provided e does so in a message that has either "Promotor" or "Proposal" in the subject line; e SHOULD NOT do so unless e believes eir proposal is certifiable and is ENCOURAGED to explain why eir proposal is certifiable. Once certification is requested, the Promotor SHALL respond publicly before publishing the next report that contains the proposal, unless the proposal is withdrawn or pended in the interim. Petitioning the Promotor to certify a proposal is DEPRECATED. --- Proposal Style Guide Players SHOULD format proposals in accordance with the following guidelines. These guidelines represent the Promotor's preferred formatting. Most of these guidelines are flexible recommendations, but where something is marked as STRONGLY DISCOURAGED, doing it is actively inconvenient for the Promotor. I. Headers and Metadata. 1. Format headers as close as possible to the heading used for distributions, which looks like this: Title: _ Adoption index: _._ Author: Co-authors: , To be clear: a) write the fields in that order; b) write out all the fields, even the ones that have default values; and c) write each field on its own line. 2. a) Give proposals titles 35 characters or less. b) Giving proposals titles over 70 characters is STRONGLY DISCOURAGED. II. Bodies. 1. Indent Proposals two spaces per indent level. 2. a) Wrap proposal lines to 80 characters or less. b) Making it so the Promotor cannot wrap lines to 80 characters or less is STRONGLY DISCOURAGED unless it is absolutely unavoidable (e.g. in the case of URLs). 3. Players are STRONGLY DISCOURAGED from placing markings that indicate the start of the proposal's text on the same line as the start of the text. ---
