GovXS / Evaluating-Voting-Design-Tradeoffs-for-Retro-Funding

Open-source simulation framework to measure how different voting designs perform against a number of typical retro funding design goals. Achieved by simulating voter behavior and applying formal, axiomatic reasoning.
MIT License
3 stars 0 forks source link

Collaboration Policies (Draft) #2

Closed AngelaKTE closed 2 months ago

AngelaKTE commented 4 months ago

Description

Read, and accept our collaboration policy. Re-open the issue, whenever you think we should update our policies
@briman @idrees @Nimrod


Collaboration Policy:

How we organize our team:

Our Workflow (for any work in Github):

  1. Choose open Issue (or create one) on Linear.
  2. Use the Copy git branch name action or shortcut Cmd/Ctrl + Shift + .
  3. Create branch on Github, include the issue ID in the branch name
  4. Move issue to "In Progress".
  5. Work on the issue.
  6. Make pull request, use a magic word before the issue ID in commit message to link issues. This will move the issue to In Progress when the commit is pushed and Done when the commit is merged. Magic words: https://linear.app/docs/github#magic-words
  7. (Optional) Request reviewers on pull request.
  8. Move Issue to "Closed" in GitHub once pull request is merged.

Working Cycles:

Policy Changes:


Tasks

Include specific tasks in the order they need to be done in. Include links to specific lines of code where the task should happen at.

linear[bot] commented 4 months ago
GOV-11 Collaboration Policies (Draft)

#### Description Read, and accept our collaboration policy. Re-open the issue, whenever you think we should update our policies @briman @idrees @Nimrod --- # Collaboration Policy: **How we organize our team:** * we meet weekly * our tasks source of truth is Linear, we create issues for anything we think should be done * everyone is allowed and encouraged to create issues * everyone is allowed to assign issues to collaborators, IF * the issue is tied to the special skills of the team member * the issue is sufficiently specified * otherwise, everyone is allowed to reject an issue * everyone is obliged to react on a personally assigned issue within a week latest (min. reaction: add a comment) **Our Workflow (for any work in Github):** 1. Choose open Issue (or create one) on Linear. 2. Use the *Copy git branch name* action or shortcut Cmd/Ctrl + Shift + . 3. Create branch on Github, include the `issue ID` in the branch name 4. Move issue to "In Progress". 5. Work on the issue. 6. Make pull request, use a magic word before the issue ID in commit message to link issues. This will move the issue to `In Progress` when the commit is pushed and `Done` when the commit is merged. Magic words: [https://linear.app/docs/github#magic-words](https://linear.app/docs/github#magic-words) 7. (Optional) Request reviewers on pull request. 8. Move Issue to "Closed" in GitHub once pull request is merged. **Working Cycles:** * we work in weekly cycles * the work for the week is defined in our weekly sync and managed via issues **Policy Changes:** * our collaboration policies should make collaboration easy * if it turns out we need changes, we change it, any time --- #### Tasks Include specific tasks in the order they need to be done in. Include links to specific lines of code where the task should happen at. - [ ] Read the policies - [ ] Make comments, @ collaborators - [ ] Confirm by closing your sub-issue - [ ] If you ever think we should update our policies, re-open the issue, update - [ ] Make everyone confirm by assigning a sub-issue

AngelaKTE commented 2 months ago