diff --git a/.gitignore b/.gitignore new file mode 100644 index 0000000000..c23c97841c --- /dev/null +++ b/.gitignore @@ -0,0 +1,222 @@ +################# +## Eclipse +################# + +*.pydevproject +.project +.metadata +bin/ +tmp/ +*.tmp +*.bak +*.swp +*~.nib +local.properties +build.properties +.classpath +.settings/ +.loadpath + +# External tool builders +.externalToolBuilders/ + +# Locally stored "Eclipse launch configurations" +*.launch + +# CDT-specific +.cproject + +# PDT-specific +.buildpath + + +################# +## Visual Studio +################# + +## Ignore Visual Studio temporary files, build results, and +## files generated by popular Visual Studio add-ons. + +# User-specific files +*.suo +*.user +*.sln.docstates + +# Build results + +[Dd]ebug/ +[Rr]elease/ +x64/ +build/ +[Bb]in/ +[Oo]bj/ + +# MSTest test Results +[Tt]est[Rr]esult*/ +[Bb]uild[Ll]og.* + +*_i.c +*_p.c +*.ilk +*.meta +*.obj +*.pch +*.pdb +*.pgc +*.pgd +*.rsp +*.sbr +*.tlb +*.tli +*.tlh +*.tmp +*.tmp_proj +*.log +*.vspscc +*.vssscc +.builds +*.pidb +*.log +*.scc + +# Visual C++ cache files +ipch/ +*.aps +*.ncb +*.opensdf +*.sdf +*.cachefile + +# Visual Studio profiler +*.psess +*.vsp +*.vspx + +# Guidance Automation Toolkit +*.gpState + +# ReSharper is a .NET coding add-in +_ReSharper*/ +*.[Rr]e[Ss]harper + +# TeamCity is a build add-in +_TeamCity* + +# DotCover is a Code Coverage Tool +*.dotCover + +# NCrunch +*.ncrunch* +.*crunch*.local.xml + +# Installshield output folder +[Ee]xpress/ + +# DocProject is a documentation generator add-in +DocProject/buildhelp/ +DocProject/Help/*.HxT +DocProject/Help/*.HxC +DocProject/Help/*.hhc +DocProject/Help/*.hhk +DocProject/Help/*.hhp +DocProject/Help/Html2 +DocProject/Help/html + +# Click-Once directory +publish/ + +# Publish Web Output +*.Publish.xml +*.pubxml + +# NuGet Packages Directory +## TODO: If you have NuGet Package Restore enabled, uncomment the next line +#packages/ + +# Windows Azure Build Output +csx +*.build.csdef + +# Windows Store app package directory +AppPackages/ + +# Others +sql/ +*.Cache +ClientBin/ +[Ss]tyle[Cc]op.* +~$* +*~ +*.dbmdl +*.[Pp]ublish.xml +*.pfx +*.publishsettings + +# RIA/Silverlight projects +Generated_Code/ + +# Backup & report files from converting an old project file to a newer +# Visual Studio version. Backup files are not needed, because we have git ;-) +_UpgradeReport_Files/ +Backup*/ +UpgradeLog*.XML +UpgradeLog*.htm + +# SQL Server files +App_Data/*.mdf +App_Data/*.ldf + +############# +## Windows detritus +############# + +# Windows image file caches +Thumbs.db +ehthumbs.db + +# Folder config file +Desktop.ini + +# Recycle Bin used on file shares +$RECYCLE.BIN/ + +# Mac crap +.DS_Store + + +############# +## Python +############# + +*.py[cod] + +# Packages +*.egg +*.egg-info +dist/ +build/ +eggs/ +parts/ +var/ +sdist/ +develop-eggs/ +.installed.cfg + +# Installer logs +pip-log.txt + +# Unit test / coverage reports +.coverage +.tox + +#Translations +*.mo + +#Mr Developer +.mr.developer.cfg + +############# +## Apache Ant +############# + +build.properties diff --git a/decision-policy.php b/decision-policy.php index 1499325c84..b96092689d 100644 --- a/decision-policy.php +++ b/decision-policy.php @@ -14,27 +14,37 @@

The Working Group strives to reach consensus via unanimous agreement. However, at times unanimity is not possible, and for the sake of continuing to work on important topics the group must arrive at a consensus decision and move forward. In the course of establishing consensus it is critical that all participants have the opportunity to express their views for consideration so that all relevant information can be used in arriving at the conclusion. Consensus indicates that a substantial number of individuals in the group support a proposal, and within the AG Working Group consensus can be achieved through this process.

Consensus is not a vote. The exact number of working group participants supporting a Call for Consensus compared to objections is not the only factor in the decision. Although significant support from the active membership is always desirable, consensus means working through objections until they are resolved either through amending the decision or in rare cases overriding the objection as laid out in Managing Dissent. In order to work through objections they must have a clear rationale based on the technical merit or with reference to the agreed scope of the work. Moving on usually means a careful approach is taken. For example, not adding something to the documentation.

Additions to normative text such as new success criteria should have a pre-defined scope. For example, the requirements for WCAG 2.1 success criteria. Where new normative text does not reach consensus the reasons should be recorded, depending on the origin of the text. For example, if the new text originated in a github issue or pull request, it could be labeled with "Unsupported addition".

-

During discussion on a topic, participants are welcome to raise objections freely to help ensure that all available information can be considered and contribute to the best possible decision. However, when the chairs issue a Call for Consensus, objections should not be raised unless the individual strongly believes the decision is the wrong one in spite of discussion, and the individual cannot "live with" the decision. Compromise on points that the individual considers suboptimal but can "live with" is an essential part of group decisions that must meet various requirements.

+

During discussion on a topic, participants are welcome to raise objections freely to help ensure that all available information can be considered and contribute to the best possible decision. However, when the chairs issue a Call for Consensus (CfC), objections should not be raised unless the individual strongly believes the decision is the wrong one in spite of discussion, and the individual cannot "live with" the decision. Compromise on points that the individual considers suboptimal but can "live with" is an essential part of group decisions that must meet various requirements. Objections from people who raised their concerns to the group during discussions may be given more consideration than objections from people who had opportunity and chose to not participate in those discussions.

  1. Discussion on a topic proceeds until the chairs believe that all points of view have been expressed and the group has considered the variety of information presented. Depending on the topic, this discussion may take a couple of days or a couple of weeks, or more.
      -
    1. Discussion can take place in any recognized channel of the Working Group including email on the AG mailing list, comment threads for GitHub issues or pull requests, or on Working Group calls.
      2. +
    2. Discussion can take place in any recognized channel of the Working Group including email on the public AG mailing list, AG surveys, comment threads for GitHub issues or pull requests, or on Working Group calls.
  2. When the chairs believe that the group is ready to come to a decision they announce a Call for Consensus by email to the Working Group's mailing list. The Call must remain open for a minimum of two working days.
      -
    1. The Call is open to responses from all group members.
      2. +
    2. The Call is open to responses from all group participants.
    3. The Call will be for a single topic, will clearly indicate that it is a Call for Consensus, and will contain pointers to the relevant discussion. This may include links to GitHub issues or pull requests, AG surveys, email threads, or meeting minutes.
    4. A resolution recorded in a WG teleconference may precede a Call for Consensus, but it may not replace the official Call for Consensus.
    5. Issues that are regarded as editorial by the Chairs do not require a Working Group decision in order for the Chairs to address, and thus do not require a Call for Consensus. If there is disagreement by participants on whether something is editorial this can be brought to the attention of the chairs either privately or in the context of the wider group.
    3. +
  3. Responding to the Call for Consensus
      +
    1. Individuals are invited, but not required, to support the decision by replying to the CfC email with “+1”, or to indicate a “can live with” status by replying with a “+0”.
      2. +
    2. Objections can be raised by replying to the CfC email with “-1”. In order to facilitate understanding and discussion, it is recommended to include a rationale which includes:
        +
      1. why the individual objects to the proposed decision;
        2. +
      2. describes how the objection was raised and considered during discussion leading to the CfC, including how reactions to the potential objection were addressed;
        3. +
      3. what alternate decision would remove the objection and be likely to gain consensus in the WG.
        4. +
      3. +
    3. Objections are subject to examination by the WG and therefore must be filed on the public record.
      4. +
  4. Evaluating the Call for Consensus.
    1. If no objections are received by the deadline, the draft decision becomes a formal decision of the Working Group.
      2. -
    2. If objections are received but the chairs believe the objections have already been considered as far as is possible and reasonable, and the reviewers providing the objections can "live with” the decision, the draft decision becomes a formal decision of the Working Group.
      3. -
    3. If objections are received that the chairs believe present substantive new information or if the chairs believe there is not a clear consensus in the Working Group, they will reopen the discussion, as detailed in section 3.3.4 of the Process Document (Reopening a Decision When Presented With New Information).
      4. -
    4. If working group member(s) continue to disagree and the chairs do not believe it presents substantive new information, or it does not meet the criteria established for adding new normative content, the chairs may decide the draft decision becomes a formal decision of the Working Group despite the objection.
      5. +
    5. If objections are received but the chairs believe the objections have already been considered as far as is possible and reasonable, and the reviewers providing the objections can “live with” the decision, the draft decision becomes a formal decision of the Working Group.
      6. +
    6. If the substance of the objections was raised during discussion leading to the CfC, the chairs may give more consideration to those objections than to objections which were not raised during the discussion leading to the CfC, and reasonably could have been.
      7. +
    7. If objections are received that the chairs believe present substantive new information that could not have been raised before or is extremely compelling, or if the chairs believe there is not a clear consensus in the Working Group, they will reopen the discussion, as detailed in section 3.3.4 of the Process Document (Reopening a Decision When Presented With New Information).
      8. +
    8. If working group member(s) continue to disagree and the chairs do not believe it presents substantive new information, or it does not meet the criteria established for adding new normative content, the chairs may decide the draft decision becomes a formal decision of the Working Group despite the objection. In this case the objection will be recorded alongside the decision in the AG Decisions page.
  5. The Working Group chairs record the Formal Decisions on the AG Decisions page on the wiki. The change to the WCAG documents is incorporated into the editors draft and recorded in the appropriate change log.