Yes, we have a process:

- At least one full release with a pending deprecation warning (silent 
  by default); 3.11 is the earliest that could take place.
- At least one full release with an active deprecation warning; 3.12 
  would be the earliest for this.
- Make the change. 3.13 would be the earliest for this.

If the change is particularly urgent, we could skip the pending warning 
and bring it forward one release, but since this isn't a critical 
security bug that needs immediate action, 3.12 would be the absolute 
earliest we could make this change.

But it is vanishingly unlikely that we would change either the names of 
the parameters, or their order, without a really good reason.

You haven't given us any convincing justification for why we should 
make this change. The os.symlink function takes its arguments in exactly 
the same order as `ln -s` takes them: original source file first, 
symbolic link destination second. We're not likely to change the order 
to be the opposite to that used by `ln`.

Different Unixes and Linuxes already use different argument names for 
`ln`, we're not obliged to match any of them. "src, dest" is fine.