Librarians Todo List

* [x] Choose repo license * **Goal**: Avoid confusion over licensing, how new contributions are being licensed, allow copying to other rust repo's (like RFCs), allow anyone to use the content without needing to ask permission. * **Proposal**: MIT/Apache for now, reconsider at a later date if something else (like CC0) would be preferred. This decision should be made soon as we start to add content. * **PR**: https://github.com/rust-lang/leadership-council/pull/6 * [x] Write a definition of the Librarian group, with a template for how we can define and record other groups. * Other examples: Project Director Selection Committee. * **Goal**: Make it clear which committees exist, who is participating in them, what they are responsible for, the expectations for them, how long they last, their processes (if relevant), communication mediums (like Zulip streams, GitHub repos, if relevant). * **Proposal**: * Track committees in the leadership-council repo in files organized in `committees/` (or `groups/`?). * Include a standardized template that contains all the fields/sections that might be useful to know (but not all sections will be required). * **PR**: https://github.com/rust-lang/leadership-council/pull/8 * Document the Council's internal operations. * **Goal**: Make it clear how the Council operates. * **Proposal**: Add a document at TODO which contains specifics about Council processes, such as meetings, internal decision making process (and how it is recorded), Committee creation, Zulip stream and GitHub repo, internal and external communication, review process (particularly scheduled reviews), etc. * Process for recording meeting minutes. * **Goal**: Public transparency to the Council meetings, with a centralized location with easy access. * **Proposal**: * Minutes for different kinds of meetings are stored in https://github.com/rust-lang/leadership-council/tree/main/minutes/ * TODO: What is the process after a meeting to transfer to the repo? * Process for recording internal decisions made by the council. * **Goal**: Record and communicate what decisions have been made. Intended to allow review by council members, and for exposure to anyone outside the council. * This may be sufficiently covered by other processes (like meeting minutes, issue tracker, etc.). But it might be good to consider if it needs something more organized. * [ ] Making sure things like council member affiliations are recorded somehow. * **Goal**: Keep track of the affiliation status so that when selecting new members that the [limits](https://rust-lang.github.io/rfcs/3392-leadership-council.html#limits-on-representatives-from-a-single-companyentity) are not exceeded. * Todo: Determine if people want their affiliation kept private? * Term limits. * **Proposal 1**: Keep a document in the council repo that records people's affiliations. * **Proposal 2**: Update the rust-lang team database to be able to attach additional metadata to team members. * See https://github.com/rust-lang/team/issues/1014 for a similar request of recording team representation. * **Issue**: https://github.com/rust-lang/leadership-council/issues/9 * Process for tracking ongoing work items. * **Goal**: Be able to know what work needs to be done or is in the process of being worked on. * **Proposal**: Use the https://github.com/rust-lang/leadership-council/issues issue tracker for all work items, leveraging labels to organize them. * Possibly use GitHub projects for a dashboard view if that seems useful. * Process/guidelines for tracking issues, proposals, backlog of things to do, etc. * **Goal**: Be able to record proposals or requests, track what needs to be done, help the Council with visibility into the workload. * **Proposal**: Use the https://github.com/rust-lang/leadership-council/issues issue tracker for all work items, leveraging labels to organize them. * Copy recommendations from https://rust-lang.github.io/rfcs/3392-leadership-council/initial-work-of-the-council.html to the issue tracker * Tracking deadlines, time-sensitive things. * **Goal**: Avoid forgetting things that need review, and to prepare before they are due. * Example: 6-months before end of term, we should know who is going to rotate out. Regular review of policy decisions. * Example: Decisions that will be reviewed at a specific point in the future. * **Proposal**: ??? * Documenting project policies. * **Goal**: Have a single place where all project-wide policy is recorded. * Handling the tracking of policy changes, announcing those, etc. * Ensuring the policy decision process (RFC process) is well-documented and linked from the Council documentation, so people know how Council public proposals happen. * **Proposal**: Use either the [Forge](https://forge.rust-lang.org/) or the [Governance](https://github.com/rust-lang/governance) site to record all policy. * Copy existing policy from [RFC 3392](https://github.com/rust-lang/governance) to this new site. Then as a separate commit, remove all the RFC-centric bits (the "proposal" aspects of it) to make it clear what has been modified. Then, all future policy changes are tracked through the git history. * Updating the forge pages, and some stuff on https://www.rust-lang.org/ (primarily around core team, and project policy, etc.) * **Goal**: Remove outdated information, avoid confusion. * The group should give a report to the council to review what has been decided since the last report. * Chance to give feedback and ask for changes.