Changes between Version 1 and Version 2 of AddingPackages/HowTo

Timestamp:

08/20/09 02:54:08 (4 years ago)

Author:

duncan (IP: 79.78.244.40)

Comment:

add links to release team and steering committee

AddingPackages/HowTo

@@ -48 +48 @@
 on ${deadline}.
 }}}
-  Obviously, you should stick in the real [wiki:AddingPackages#Deadlines discussion deadline] that the release team have announced.
+  Obviously, you should stick in the real [wiki:AddingPackages#Deadlines discussion deadline] that the [wiki:Members#ReleaseTeam release team] have announced.
 
 ''Credits''
@@ -142 +142 @@
 }}}
 
-There is a window in each release cycle for discussing new packages. The release team will announce the [wiki:AddingPackages#Deadlines deadlines]. There's a deadline for you to send in your proposal and then a later deadline for the end of the discussion period.
+There is a window in each release cycle for discussing new packages. The [wiki:Members#ReleaseTeam release team] will announce the [wiki:AddingPackages#Deadlines deadlines]. There's a deadline for you to send in your proposal and then a later deadline for the end of the discussion period.
 
 There is no earliest time you can send in your proposal however, so go, send your proposal!
@@ -152 +152 @@
 Often it will make sense to incorporate answers to reviewers' questions into the proposal itself. If there isn't an obvious place in the proposal to put the answer then you might like to just stick them into a Q&A section.
 
-Issues and complaints raised by reviewers should be tracked, for example in an "open issues" section. A simple way to do this is to give a one-sentence summary and link to the mailing list post where the issue was raised. A member of the steering committee might help you out with this, especially if the decision seems like it's going to be controversial. You're not expected to fix everything reviewers ask for, or to fix things straight away, but it would be helpful to indicate which issues you think can and should be addressed. 
+Issues and complaints raised by reviewers should be tracked, for example in an "open issues" section. A simple way to do this is to give a one-sentence summary and link to the mailing list post where the issue was raised. A member of the [wiki:Members#SteeringCommittee steering committee] might help you out with this, especially if the decision seems like it's going to be controversial. You're not expected to fix everything reviewers ask for, or to fix things straight away, but it would be helpful to indicate which issues you think can and should be addressed. 
 
 Ultimately, the criteria to get your package accepted is that the reviewers come to a consensus and agree to accept it. Sometimes reviewers will disagree with each other or with you. See the suggestions on how to [wiki:AddingPackages#Consensus achieve consensus]. Keep in mind that it is OK to get a consensus for [wiki:AddingPackages#Acceptance conditional acceptance], where you or the maintainers promise to make certain changes before the package gets included into a release.