update org requirements to 12 months (#204)

Reduces duration of inactive member policy from 18 to 12 months

Based on the experience from K8s kubernetes/community#7380

Signed-off-by: Bill Mulligan <[email protected]>

CONTRIBUTOR-LADDER.md

@@ -19,7 +19,7 @@ Each of the contributor roles below is organized into three types of lists:
 
 As the Cilium project grows, the current roles may be broken out into new roles and/or teams and roles may no longer be needed. 
 
-The final judgment on whether an individual fulfills the criteria for a role is up to the Cilium Committers. After six months of inactivity for Committers and Reviewers, 18 months of inactivity for Organization Members, or after any behavior detrimental to the future of the project, any contributor can be removed from their position(s).
+The final judgment on whether an individual fulfills the criteria for a role is up to the Cilium Committers. After six months of inactivity for Committers and Reviewers, 12 months of inactivity for Organization Members, or after any behavior detrimental to the future of the project, any contributor can be removed from their position(s).
 
 ### Community Contributor
 
@@ -169,7 +169,7 @@ Therefore members with an extended period away from the project with no activity
 
 #### How inactivity is measured
 
-Inactive members are defined as members of the Cilium org with **no** contributions across any repository within 18 months. This is measured by the CNCF [DevStats project](https://cilium.devstats.cncf.io/d/8/dashboards?orgId=1&refresh=15m).
+Inactive members are defined as members of the Cilium org with **no** contributions across any repository within 12 months. This is measured by the CNCF [DevStats project](https://cilium.devstats.cncf.io/d/8/dashboards?orgId=1&refresh=15m).
 
 **Note:** Devstats does not take into account non-code contributions. If a non-code contributing member is accidentally removed this way, they may open an issue to quickly be re-instated.
 
@@ -181,4 +181,4 @@ As an open source project, we don’t make any guarantees about how quickly prop
 
 Naturally, the more an individual has already contributed to the project, the higher the level of trust and confidence that the person will have established in the community. Starting with smaller proposals, fixes and maintenance work, or making constructive and meaningful review comments on other people's suggestions, can help build up that trust and confidence. 
 
-Accepting any change into the project means that the committers are signing up to maintain it going forward. To quote [Solomon Hykes](https://x.com/solomonstre/status/715277134978113536?s=20), "no is temporary, yes is forever". For major changes, being willing to push through the development work may not be enough - it’s likely you will need a track record of contributions to convince the community that you’ll be around to maintain changes into the future. 
+Accepting any change into the project means that the committers are signing up to maintain it going forward. To quote [Solomon Hykes](https://x.com/solomonstre/status/715277134978113536?s=20), "no is temporary, yes is forever". For major changes, being willing to push through the development work may not be enough - it’s likely you will need a track record of contributions to convince the community that you’ll be around to maintain changes into the future.