NOTA BENE - WORK IN PROGRESS - Your Inputs & Thoughts
To CAcert.org Identity
CAcert.org Communication & Communications
- Description of Difference
more about Communication - source: en.wikipedia.org
more about Communications -source: en.wikipedia.org
CAcert.org Communication Practice (Proposal)
- Introduction
CAcert.org Official Statements and Messages are announced by CAcert Inc. Committee (Board of Directors)
Messages by CAcert.org Community Members
To be respected, CAcert.org Glossary & Abbreviations
CAcert.org Communications Practice (Proposal)
- Introduction
- Principels
CAcert.org Communication Policy (Proposal)
- Basis for CAcert.org Communication and CAcert.org Communications Practice
- Text Proposal for Policy:
Inputs & Thoughts
20090814-Iang
== CAcert.org Communitcation & Communitcations - Current Practice == According to [[https://community.cacert.org/board/motions.php?motion=m20090815.4|m20090815.4]]: || '''''RESOLVED''', that the board prepare a new communications practice that is substantially open and community-driven, and'' || || '''''FURTHER RESOLVED''' that this new communications practice is intended to replace the CAcertCommunication\"Policy\". '' || == A Starter on Communications Principles == === Access to Community Weapons === Where a system is not a critical system, and is for the purposes of community work, access control to the benefits of the application should be light (''hugi: definition of light?''). In general this applies to these applications: Blog, IRC, Email, Maillists, SVN, etc. By default, all members who are Assurers ''and'' are in assigned roles are to be automatically given access. An administrator should apply common sense in adding people without "roles" and should think broadly and inclusively. If members have the skills, put them to use! Administrators should keep a reviewable list of who has access to what. As a technical and systems priority, certificates should be used where and when possible. Administrators should pursue certificate access as the preferred method of access control, unless it is slowing down access to the real resource. At least two administrators should be listed for each access, and either of them can add members. Any differences in opinion can be referred upwards to infrastructure team leader / board. Ultimately, as all our members are under CCA and Arbitration, the final place for disputes would be Arbitration, but that is not expected. The board is to keep a list of systems that have some form of "tight control" on them. See Appendix 1. The board can approve tight access control, but does so cautiously because we are an open organisation. === Formal Statements === Formal Statements by the Association are to be signed (words or cert) by a Director, with the words "for the Board of CAcert" or similar so as to indicate that these are official announcements. It should be accompanied by a Board Resolution, as referenced with a motion number. E.g., see top. Other Statements of formal import are also described and authorised under the [[DecisionNumbers]] page. === CAcert email addresses === Your CAcert email address should be used for all CAcert-related business. A use of an email address does not indicate an official statement. Emails & posts are contributions as per CCA. === Appendix 1. Systems with Tighter Control === * COD * placing items in draft/policy status limited to documentation officer as approved * accounts - restricted interface for support persons * Paypal * banks * maillists: * list-admin list (private) * cacert-arbitration and cacert-disputes (private) * support@ email address (private) * private board list (private) * private members list (private) * system log list (no-post) * key persons registry (private) * blog: * (maybe) one formal account under name of CAcert Board (held by board, not currently used) * (or) only, board identifies itself in text * SVN: * critical code is controlled by software assessment team * AuditI (private) * email address * some role-titled email addresses are limited to approved people: privacy, audit, treasurer, secretary... * name-titled email addresses are to be more open * Members email addresses in online system * accessible by officers & directors (implementation dependent) === Appendix 2 -- deprecated === Note this practice replaces [[http://wiki.cacert.org/wiki/EmailBoardDecisions2008-09|m20090310.2]] and [[https://svn.cacert.org/CAcert/Policies/CAcertCommunicationPolicy.html|CCP]]
20090911-DanielBlack
Features: * Author privileges to named certificates * Contributor (moderated posts) for unnamed certificates * Existing accounts still work if you have a certificate for the email address matching your account * Existing accounts will update to Author privileges when a named certificate is presented. * Autoregistration on presenting a certificate to login or manually doing a registration with a certificate. Non-Features: * Due to the complexity and limited time for testing dual support of certificate and password logins has been dropped in favour of only certificate logins. Password logins may be examined if there is a need. The plan is to test it a bit more hopefully next week and deploy it a week after. We'll let you know when it is done. If anyone wants to do a code review let us know. New registrations have been temporarily disabled due to blog spam that I'm feeling obliged to moderate. Thanks,
YYYYMMDD-YourName
Text / Your Statements, thoughts and e-mail snippets, Please
YYYYMMDD-YourName
Text / Your Statements, thoughts and e-mail snippets, Please
Category or Categories