- 
                Notifications
    
You must be signed in to change notification settings  - Fork 79
 
add merge and publication policy #2363
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: develop
Are you sure you want to change the base?
Conversation
          ✅ Deploy Preview for act-rules ready!
 To edit notification comments on pull requests, go to your Netlify project configuration.  | 
    
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One concern around handling merges to the act-rules.github.io and just a couple minor tweaks to the wording. I am also requesting for Rémi to decide if he's comfortable with this or he has other thoughts he wants to add in here.
| 
               | 
          ||
| ### Merge and publication policy | ||
| 
               | 
          ||
| To give implementors of ACT Rules time to update implementation data, pull requests cannot be merged on Friday, Saturday, or Sunday. Those three days are reserved for implementors to update their implementation data (automated or otherwise). The publication cycle works as follows: | 
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What happens if something gets merged on Monday, or on Tuesday, right before the WAI website update goes live? As I said yesterday, I think we should restrict the updates coming from the act-rules.github.io repo to a specific date and time during the week, which could be Thursdays after the meeting when hopefully all has been merged.
| 
               | 
          ||
| 1. Pull requests in [act-rules/act-rules.github.io][] can be merged Monday through Thursday. | ||
| 2. Implementors have Friday, Saturday or Sunday to update implementation data. | ||
| 3. Monday morning a publication candidate is created as a pull request in [w3c/wcag-act-rules][], for review by WAI staff. | 
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| 3. Monday morning a publication candidate is created as a pull request in [w3c/wcag-act-rules][], for review by WAI staff. | |
| 3. Monday morning, a pull request for updating the WAI website is created in [w3c/wcag-act-rules][], for review by WAI staff. | 
| 1. Pull requests in [act-rules/act-rules.github.io][] can be merged Monday through Thursday. | ||
| 2. Implementors have Friday, Saturday or Sunday to update implementation data. | ||
| 3. Monday morning a publication candidate is created as a pull request in [w3c/wcag-act-rules][], for review by WAI staff. | ||
| 4. Somewhere that week, usually Monday or Tuesday, the publication candidate is approved and published to the WAI website. | 
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| 4. Somewhere that week, usually Monday or Tuesday, the publication candidate is approved and published to the WAI website. | |
| 4. Sometime during the week, usually Monday or Tuesday, the pull request is approved and published to the WAI website. | 
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| 4. Somewhere that week, usually Monday or Tuesday, the publication candidate is approved and published to the WAI website. | |
| 4. The publication candidate is approved and published to the WAI website. This usually happens sometime during the week, typically Monday or Tuesday. For more information, see the [publication workflow](https://wai-website-theme.netlify.app/workflow/). | 
We strive to (and usually) approve and publish during the week, but sometime it is delayed.
I also think good to point to the publication process.
| 3. Monday morning a publication candidate is created as a pull request in [w3c/wcag-act-rules][], for review by WAI staff. | ||
| 4. Somewhere that week, usually Monday or Tuesday, the publication candidate is approved and published to the WAI website. | ||
| 
               | 
          ||
| For substantial changes, implementors may request a publication be skipped to allow extra time for implementation. This should be done on the publication candidate pull request. It is up to discretion of W3C staff to decide whether the publication is skipped. | 
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| For substantial changes, implementors may request a publication be skipped to allow extra time for implementation. This should be done on the publication candidate pull request. It is up to discretion of W3C staff to decide whether the publication is skipped. | |
| For substantial changes, implementors may request that a publication be skipped to allow extra time for implementation. This should be done on the WAI website pull request. It is at the discretion of W3C staff to decide whether the publication is skipped. | 
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| For substantial changes, implementors may request a publication be skipped to allow extra time for implementation. This should be done on the publication candidate pull request. It is up to discretion of W3C staff to decide whether the publication is skipped. | |
| For substantial changes, implementors may request that a publication be skipped to allow extra time for implementation. This should be done on the pull request in [w3c/wcag-act-rules][]. It is up at the discretion of W3C staff to decide whether the publication is skipped. | 
Minor. @daniel-montalvo please note that I've included your suggested changes in my suggestion.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@daniel-montalvo Thanks for the opportunity to review. I've added a couple comments to address before merging.
Please note that I've only focused on step 4 that happens in the w3c/wcag-act-rules repository.
The workflow for publishing updates to the WAI website is documented at https://wai-website-theme.netlify.app/workflow/
It is my understanding that this PR documents this part of the workflow:
Each Working Group and editorial team defines their own workflow for drafting, reviewing, approving, and submitting updates.
| 
           Can we discuss this briefly during our regular meeting? Is it okay if I add it to the agenda?  | 
    
| 
           We need to put this on the agenda. I don't think limiting merges to a single day is the right solution. If we want a more controlled release flow the way to do it is through release candidates. That's standard practice in lots of places. The other option as that we don't try to do this. This hasn't ever really been an issue. If coming up with a process is a big hassle we should consider if we want this at all.  | 
    
          
 I open a pr on the w3c repo 
 Looking forward to hearing what other implementers think about this.  | 
    
This comes out of a conversation during office hours today. We don't have a documented process that ensures implementors have sufficient time to update before we publish new rules / test cases. This should address that.
Need for Call for Review: 2 weeks
How to Review And Approve