Add New Maintainer

## Maintainer Update Proposal

### Type of Update:

- [x] **Add New Maintainer** - Proposing to add a new maintainer to the project
- [ ] **Remove Maintainer** - Proposing to remove an existing maintainer from the project

---

### Maintainer Details:

**Name:** Shivaji Byrapaneni

**GitHub Handle:** @byrash

**Component/Module:** All

---

## For New Maintainer Additions

### Contribution History:

...describe the substantial contributions this person has made to the project, including:

- Number and significance of pull requests merged
Rewrite of CALM Plugin is in PR Process
- Participation in issue discussions and reviews
Already part of WG & Issue Discussions from past few months
- Documentation contributions
- Community engagement (Office Hours, meetings, etc.)
- Any other relevant contributions

### Why This Person Should Be a Maintainer:

As an active member of CALM WG & adding value to enhance CALM eco system. I wish to be a maitainer.

### Links to Contributions:

- PR: https://github.com/finos/architecture-as-code/pull/2896
- Issue: https://github.com/finos/architecture-as-code/issues/2869
https://github.com/finos/architecture-as-code/issues/2868
- Other:

---

## For Maintainer Removals

### Reason for Removal:

- [ ] **Voluntary** - The maintainer has requested to be removed
- [ ] **Inactivity** - The maintainer has been inactive (see criteria below)

### Rationale:

...provide clear reasoning for the removal proposal:

**For Voluntary Removals:**
- State that the maintainer has requested to step down
- Include any relevant context they've provided (optional)

**For Inactivity Removals:**
- Confirm the maintainer has had no commits AND no involvement in issues/PRs for **3+ months**
- Specify the period of inactivity (e.g., "no activity since [DATE]")
- Note: This removal proposal does NOT reflect negatively on the individual, but rather acknowledges changes in their ability to contribute
- Explain why having the README.md reflect active maintainers is important for the project

### Notice Period:

**Issue Created:**

**Notice Period Ends:**

**Vote May Proceed After:**

### Maintainer Notification:

- [x] Maintainer tagged in this issue
- [ ] Maintainer contacted via email (if contact info available)
- [ ] Other notification methods used (specify):

---

## Voting Process

As per [Governance.md](https://github.com/finos/architecture-as-code/blob/main/Governance.md):

- All members of **@finos/architecture-as-code-maintainers** are eligible to participate
- Please register your vote by commenting with:
- `+1` to approve the proposal
- `-1` to reject the proposal
- `+0` to abstain

**For New Maintainer Additions:**
- The nomination MUST receive a majority of votes to be approved
- All discussion and voting will take place publicly in the comments on this issue

**For Voluntary Removals:**
- No vote is required; Maintainers should acknowledge and proceed with removal

**For Inactivity Removals:**
- A minimum **4-week notice period** MUST be observed before voting
- If the maintainer responds or resumes activity during the notice period, this issue SHOULD be closed without a vote
- After the notice period, a vote will be held if the maintainer has not responded or resumed activity

**Voting Period:**

Unless consensus is reached earlier, this issue will remain open for voting and will be closed **on or after [DATE - typically 1 week after notice period for removals, or 1-2 weeks for additions]**, at which point the outcome will be recorded.

---

## Implementation Checklist

**For Additions:**
- [ ] Add maintainer to the GitHub team: `@finos/architecture-as-code-maintainers`
- [ ] Update `README.md` to list the new maintainer
- [ ] Update `.github/CODEOWNERS` if they will be owning specific components
- [ ] Welcome the new maintainer in the project channels

**For Removals:**
- [ ] Remove maintainer from the GitHub team: `@finos/architecture-as-code-maintainers`
- [ ] Update `README.md` to remove the maintainer from the list
- [ ] Update `.github/CODEOWNERS` to reassign their owned components
- [ ] Thank the maintainer for their contributions in the project channels (if appropriate)

---

## Additional Context

...add any other relevant context, history, or information about this proposal...

Read Governance.md first to confirm the voting requirements and notice periods. If the nomination is approved, follow the implementation checklist across README.md, .github/CODEOWNERS, the GitHub maintainers team, and project channels; done means the vote is recorded and the approved maintainer details are updated.

Written by the indexing model from the issue text.