[wp-trac] [WordPress Trac] #33161: Create a standard for defining and identifying site environment

WordPress Trac noreply at wordpress.org
Tue Jun 30 19:12:21 UTC 2020


#33161: Create a standard for defining and identifying site environment
--------------------------------------+-----------------------------
 Reporter:  krogsgard                 |       Owner:  SergeyBiryukov
     Type:  enhancement               |      Status:  reopened
 Priority:  normal                    |   Milestone:  5.5
Component:  Options, Meta APIs        |     Version:  4.2
 Severity:  normal                    |  Resolution:
 Keywords:  needs-dev-note has-patch  |     Focuses:
--------------------------------------+-----------------------------

Comment (by pbiron):

 Replying to [comment:49 kraftbj]:
 > > * Would there be any objection to also includinig `'qa'` and `'uat'`
 in the default list of environments?
 >
 > No objection per se, but I'd like in the dev notes (and ideally in
 inline documentation IMO) some explanation of what each is intended to
 mean.

 Since the suggestion for adding those came from me, let me explain what I
 mean by them (actually, the following is how they've been used by clients
 I've worked with):

 1. `qa` and `uat` are distinct from `development` and `staging` in that
    1. no code or content changes happen (other than pushes from some
 "other" environment)
    2. they **never** get pushed to production (like `staging`), tho they
 do get pushed to `staging`
 2. `uat` (User Acceptance Testing) is for review/sign-off on both
 functionality and look-and-feel by **stake holders**
 3. `qa` (Quality Assurance) is for review/sign-off by parties that are not
 stake holders, e.g.,
    1. the legal department approving final copy (e.g., changes to Privacy
 Policy text)
    2. outside auditors (e.g., accessibility audits, when there are **legal
 requirements** for Level A vs AA vs AAA WCAG compliance, and the expertise
 to do that review is not available in-house)

 **Maybe** those environments (and the purposes they are used for) are
 peculiar to the clients I've worked with, in which case I have no problem
 with them not being included in core (since they can always be added via
 the `wp_environment_types` filter).

 Hope this helps.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/33161#comment:50>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list