[Infrastructure] Updated instructions for GitHub ballot merge after IPR review

[Dimitris Zacharopoulos (HARICA)]

During the latest SC33 merge into main,

Wayne had to do some additional commits to bring the pull request up to 
speed before being able to create a merge request for SC33.

According to the current process documented in 
https://wiki.cabforum.org/github_redline_guide#chair_or_vice_chair_onlyactions_before_the_ipr_review_period_chair_or_vice_chair,

step 3. says "Open the existing “Pull Request” that contains the 
immutable red line.".

In some of the recent ballots (SC33, SC28) there were no pull requests 
but instead just immutable compare links. My first question is how can 
the Chair (or Vice Chair) create such a pull request, when the changes 
are in a private fork (e.g. Neil's or Wayne's fork)?


Assuming there is such a pull request in some private fork, and assuming 
that there has already been an update in the Baseline Requirements 
document in between, the workflow should be updated to include some 
additional steps in the forked repo:

3a: re-sync the forked repo with the cabforum/documents main branch. How 
does this "re-sync" process look like from a practical standpoint?
3b: resolution of any conflicts so that the end result of the pull 
request will be against the "latest" version of the BRs in 
cabforum/documents main

Are there any other issues to consider? I know that Wayne spent some 
time doing this over SC33 so he could share his experience so we can all 
help updating the documentation on the wiki.


Thanks,
Dimitris.

PS: I will soon need to do this when the IPR review period is over for 
SC28 and SC35