BizApps Wiki, the free Business Applications encyclopedia:Policies and guidelines

From BizApps Wiki, the free Business Applications encyclopedia
Jump to: navigation, search

BizApps Wiki's policies and guidelines are developed by the community to describe best practices, clarify principles, resolve conflicts, and otherwise further our goal of creating a free, reliable encyclopedia about business applications and other related topics. There is no need to read any policy or guideline pages to start editing.

Although BizApps Wiki generally does not employ hard-and-fast rules, BizApps Wiki's policy and guideline pages describe its principles and agreed-upon best practices. Policies are standards all users should normally follow, and guidelines are generally meant to be best practices for following those standards in specific contexts. Policies and guidelines should always be applied using reason and common sense.

This policy page specifies the community standards related to the organization, life cycle, maintenance of, and adherence to policies, guidelines, and related pages of the BizApps Wiki.

Derivation

"BizApps Wiki" is operated by the Tounca LLC, which reserves certain legal rights. Nevertheless, normally "BizApps Wiki" is a self-governing project run by its community. Its policies and guidelines are intended to reflect the consensus of the community.

Role

Policies have wide acceptance among editors and describe standards all users should normally follow.

Guidelines are sets of best practices supported by consensus. Editors should attempt to follow guidelines, though they are best treated with common sense, and occasional exceptions may apply.

Essays are the opinion or advice of an editor or group of editors for which widespread consensus has not been established. They do not speak for the entire community and may be created and written without approval. Essays the author does not want others to edit, or that contradict widespread consensus, belong in the user namespace.

Some other pages even if they are not policies or guidelines, although they may contain valuable advice or information.

Adherence

Use common sense in interpreting and applying policies and guidelines; Rules have occasional exceptions. That said, those who violate the spirit of a rule may be reprimanded or sanctioned even if they do not technically break the rule.

Enforcement

Enforcement on BizApps Wiki is similar to other social interactions. If an editor violates the community standards described in policies and guidelines, other editors can persuade the person to adhere to acceptable norms of conduct, over time resorting to more forceful means, such as administrator actions. In the case of gross violations of community norms, they are likely to resort to more forceful means fairly rapidly. Going against the principles set out on these pages, particularly policy pages, is unlikely to prove acceptable, although it may be possible to convince fellow editors an exception ought to be made. This means individual editors (including you) enforce and apply policies and guidelines.

In cases where it is clear a user is acting against policy (or against a guideline in a way that conflicts with policy), especially if they are doing so intentionally and persistently, that user may be temporarily or indefinitely blocked from editing by an administrator. In cases where the general dispute resolution procedure has been ineffective, the Arbitration Committee has the power to deal with highly disruptive or sensitive situations.

­Content

Policy and guideline pages should:

  • Be clear. Avoid esoteric or quasi-legal terms or dumbed-down language. Be plain, direct, unambiguous, and specific. Avoid platitudes and generalities. Even in guidelines, help pages, and other non-policy pages, do not be afraid to tell editors directly they must or should do something.
  • Be as concise as possible—but no more concise. Verbosity is not a reliable defense against misinterpretation. Omit needless words. Direct, concise writing may be clearer than rambling examples. Footnotes and links to other pages may be used for further clarification.
  • Emphasize the spirit of the rule. Expect editors to use common sense. If the spirit of the rule is clear, say no more.
  • Maintain scope and avoid redundancy. Clearly identify the purpose and scope early in the page, as many readers will just look at the beginning. Content should be within the scope of its policy. When the scope of one advice page overlaps with the scope of another, minimize redundancy. When one policy refers to another policy, it should do so briefly, clearly and explicitly.
  • Keep scope in business application. This is not encyclopedia in general; for this purpose, we can recommend to use https://en.wikipedia.org/. This is encyclopedia about business software and applications as well as other related topics. These related topic can be business processes, accounting, marketing (if this is connected with some CRM solutions), project management, implementation or development of these systems... Do not create content not related with these topics, using your common sense.
  • Avoid overlinking. Links to policies, guidelines, essays, and articles should be used only when clarification or context is needed. Links to other advice pages may inadvertently or intentionally defer authority to them. Make it clear when links defer, and when they do not.
  • Not contradict each other. The community's view cannot simultaneously be "A" and "not A". When apparent discrepancies arise between pages, editors at all the affected pages should discuss how they can most accurately represent the community's current position and correct all the pages to reflect the community's view. This discussion should be on one talk page, with invitations to that page at the talk pages of the various affected pages; otherwise the corrections may still contradict each other.

Not part of the encyclopedia

The policies, guidelines, and process pages themselves are not part of the encyclopedia proper. Consequently, they do not generally need to conform to the same content standards or style conventions as articles. It is therefore not necessary to provide reliable sources to verify administrative pages, or to phrase BizApps Wiki procedures or principles in a neutral manner, or to cite an outside authority in determining editorial practices. Instead, the content of these pages is controlled by community-wide consensus, and the style should emphasize clarity, directness, and usefulness to other editors.

These pages do, however, need to comply with BizApps Wiki's legal and behavioral policies, as well as policies applicable to non-content pages. For example, editors may not violate copyrights anywhere on "BizApps Wiki", and edit warring is prohibited everywhere, not merely in encyclopedia articles.

Life cycle

The most of policies and guidelines have developed as solutions to common problems and disruptive editing. Policy and guideline pages are seldom established without precedent and always require strong community support. Policies and guidelines may be established through new proposals, promotion of existing essays or guidelines, and reorganization of existing policies and guidelines through splitting and merging.

Current policy and guideline proposals can be found in BizApps Wiki proposals, and failed proposals can be found in BizApps Wiki failed proposals. All editors are welcome to comment on these proposals.

Proposals

Proposals for new guidelines and policies require discussion and a high level of consensus from the entire community for promotion to guideline or policy. Most commonly, a new policy or guideline documents existing practices, rather than proposing a change to what experienced editors already choose to do.

Good practice for proposals

One path for proposals is developing them through steps of brainstorming, draft proposal, proposal, policy or guideline. The first step is to write the best initial proposal you can. Authors can request early-stage feedback at BizApps Wiki Ideas Lab. Amendments to a proposal can be discussed on its talk page. It is crucial to improve a proposal in response to feedback received from outside editors. Consensus is built through a process of listening to and discussing the proposal with many other editors.

Once you think the initial proposal is well written, and the issues involved have been sufficiently discussed among early participants to create a proposal that has a solid chance of success with the broader community, start an RfC for your policy or guideline proposal in a new section on the talk page. Then, if you want, you can provide a detailed explanation of what the page does and why you think it should be a policy or guideline. RfCs for policy and guideline proposals are normally left open for at least a week or sometimes a couple months.

To avoid later complaints about insufficient notice, it may be helpful to provide a complete list of the groups or pages you used to advertise the proposal on the talk page.

Editors should respond to proposals in a way that helps identify and build consensus. Explain your thoughts, ask questions, and raise concerns. Many editors begin their responses with bold-font 'vote' of support or opposition to make evaluation easier.

Closing a discussion requires careful evaluation of the responses to determine the consensus. This does not require the intervention of an administrator; it may be done by any sufficiently experienced impartial editor, not involved in the discussion, who is familiar with all policies and guidelines related to the proposal. The following points are important in evaluating consensus:

  • Consensus for guidelines and policies should be reasonably strong, though unanimity is not required.
  • There must be exposure to the community beyond just the authors of the proposal.
  • Consider the strength of the proposed page:
    • Have major concerns raised during the community discussion been addressed?
    • Does the proposal contradict any existing guidelines or policies?
    • Can the new proposed guideline or policy be merged into an existing one?
    • Is the proposed guideline or policy, or some part of it, redundant with an existing guideline or policy?
  • A proposal's status is not determined by counting votes.
  • If consensus for broad community support has not developed after a reasonable time, the proposal has failed. If consensus is neutral or unclear on the issue and unlikely to improve, the proposal has likewise failed.

Discussion may be closed as one of: Promote, No consensus, or Failed. Please leave a short note about the conclusion you came to. Update the proposal to reflect the consensus.

Demotion

An accepted policy or guideline may become obsolete because of changes in editorial practice or community standards, may become redundant because of improvements to other pages, or may represent unwarranted instruction creep. In such situations editors may propose that a policy be demoted to a guideline, in which case the old page is marked and retained for historical interest.

The process for demotion is similar to promotion. After a reasonable amount of time for comments, an independent editor should close the discussion and evaluate the discussion and determine whether a consensus has formed to change the status.

Essays, information pages, and other informal pages that are supported by only a small minority of the community are typically moved to the primary author's userspace. These discussions typically happen on the page's talk page, sometimes with an RfC. Other pages are retained for historical reference and are marked as such.

Content changes

Policies and guidelines can be edited like any other BizApps Wiki page. It is not strictly necessary to discuss changes or to obtain written documentation of a consensus in advance. However, because policies and guidelines are sensitive and complex, users should take care over any edits, to be sure they are faithfully reflecting the community's view and to be sure they are not accidentally introducing new sources of error or confusion.

Because BizApps Wiki practice exists in the community through consensus, editing a policy/guideline/essay page does not in itself imply an immediate change to accepted practice. It is, naturally, bad practice to recommend a rejected practice on a policy or guideline page. To update best practices, you may change the practice directly (you are permitted to deviate from practice for the purposes of such change) and/or set about building widespread consensus for your change or implementation through discussion. When such a change is accepted, you can then edit the page to reflect the new situation.

Substantive changes

Talk first. Talk page discussion typically precedes substantive changes to policy. Changes may be made if there are no objections or if discussion shows there is consensus for the change. Minor edits to improve formatting, grammar, and clarity may be made at any time.

If the result of discussions is unclear, then it should be evaluated by an administrator or other independent editor, as in the proposal process. Major changes should also be publicized to the community in general; announcements similar to the proposal process may be appropriate.

Or be bold. The older but still valid method is to boldly edit the page. Although most editors find prior discussion, especially at well-developed pages, very helpful, directly editing these pages is permitted by BizApps Wiki's policies. Consequently, you should not remove any change solely on the grounds that there was no formal discussion indicating consensus for the change before it was made. Instead, you should give a substantive reason for challenging it and, if one hasn't already been started, open a discussion to identify the community's current views. A bold edit that has been reverted (with a substantive reason given) should not be reinstated without consensus.

Conflicts between advice pages

If policy and/or guideline pages directly conflict, one or more pages need to be revised to resolve the conflict so all the conflicting pages accurately reflect the community's actual practices and best advice. As a temporary measure during that resolution process, if a guideline appears to conflict with a policy, editors may assume the policy takes precedence.

More commonly, advice pages do not directly conflict, but provide multiple options. Editors must use their best judgement to decide which advice is most appropriate and relevant to the specific situation at hand.

Naming

The page names of policies and guidelines usually do not include the words "policy" or "guideline", unless required to distinguish the page from another.

Notes