fedora-budget

Clone
Source Code
GIT

#18 Create standard operating procedure for this repo
Opened 7 years ago by jflory7. Modified 2 years ago

Open
Close issue as:
Invalid Insufficient data Fixed Duplicate

Problem

It's unclear how regional treasurers are expected to interact and participate with the Fedora budget through this repository.

Analysis

A lot of work was done in setting up this repository as a method for publicly tracking expenses. I think using Pagure is an effective solution and if properly taken care of, it will be an effective tool for us. But right now, there is no clear information for how a treasurer is expected to contribute to this repository or what the expectations even are.

A high priority item for this should be to create a standard operating procedure (SOP) either as a separate DOC or in the README about what treasurers will do with this repository, how they are expected to contribute information, and maybe any details / information about when this information is expected each fiscal year.

Implementation

  1. Understand how treasurers reported this information in the past for background context
  2. Discuss with treasurers / regional representatives about how to help make it easier to contribute this information and what their needs are
  3. Begin drafting a first set of guidelines for how to contribute to the fedora-budget repository
  4. Share and put to vote with the Fedora Council
  5. Begin following this SOP for all future engagements in this repository

I'll begin working on this, albeit a bit slowly because of upcoming FUDCons.

Karma has it that I will inherit my own issue. :grinning: While I want to revisit process and guidelines for Fedora Budget, first I want to begin with an exploration of how this workflow could move to GitLab. For this particular case, migrating issue history with respect to privacy is critical. There are two requirements for moving this repo and workflow to GitLab:

  1. Migrate existing Pagure issues to GitLab.
  2. Ensure private issues remain private, and has tight access controls on who can view this data. Likely need to sync with CPE once the issue migration question is answered.

Metadata Update from @jflory7:
- Issue assigned to jflory7 (was: bex)
- Issue priority set to: Waiting on Assignee
- Issue tagged with: waiting-on-assignee
2 years ago

Login to comment on this ticket.

Metadata

waiting-on-assignee

None
Waiting on Assignee
Powered by Pagure 5.13.3
Documentation • File an Issue • About • SSH Hostkey/Fingerprint
© Red Hat, Inc. and others.