Role w.r.t. Member Companies

  • Work Groups prioritize and prefer RISE members to external parties.

Role w.r.t. External Parties

External parties include all relevant non-RISE stakeholders for the WG's work. This includes non-RISE members, OSS communities and projects, external tasks groups.

  • RISE is a tool for efficient execution within OSS communities and projects, focusing on:
    • Commerical-grade RISC-V support.
    • Self-sustaining support for RISC-V within upstream projects as a long term goal.
  • No posturing - RISE represents individual interests of RISE members.
  • RISE is complementary, not duplicative. WGs do not duplicate existing project/community infrastructure (including "RISE forks", "RISE releases", additional discussion lists/forums)
  • WG embrace transparency, building bridges with all stakeholders. This includes active sharing of RISE priorities/status in a manner that is usual for the upstream project.
  • WGs do not silo themselves off and are responsible for tracking their ecosystems (being aware of what is being done, why, what blockers/challenges exist).

Confluence

Confluence is the main way WGs interact with internal and external parties. The WG pages are used to report updates for the TSC meetings, and every RISE-funded/prioritized project must have an up-to-date page listing that helps answer what is being done, why it's important, how is it going to be done and when it will be complete:

  • About
    • Introduce the context behind the work.
  • Project Scope and Timelines
    • Define the requirements, the work being done, and by when the work ought to be completed.
  • Components and Repos
    • Identify repos and components that work will include. Include any proof-of-concepts and existing patchwork as well.

  • Stakeholders and Partners

    • Who needs to be included in design, implementation, review or testing? Include here RISE contacts (using @PersonName) and external parties (other partners, key upstream project contacts) 
  • Dependencies
    • Do you depend on something being done in another WG? Do you need some spec work?
  • Measure of success
    • How will the Board know the project succeeded?
  • RISE Requirements
    • What do you need from the RISE Board?
  • Periodic Updates
    • Add key updates here, using heading 2 with the update date as the title. 
    • Include:
      • Relevant technical decisions that are impacting the project
      • Delays
      • Links to important technical discussions (on upstream channels, of course)
      • References to patches.

Confluence is viewed as the single source of truth. No entries == no progress. Anyone should be able to view the page and get at least a rough sense of what's going on. This has implications on the quality of how the information is presented.

Projects that are not written up are not RISE projects - there's no deduplication and collaboration possible in an environment where companies silently do work.

Confluence is not an engineering log or an attic for obsolete information. Pages need to be maintained and revised to reflect reality. All in all, this enables passive updates of RISE progress to all interested parties.

Work Group Mailing Lists

The WG mailing list is the primary communication tool for a WG. Communicate early and often. If a WG chooses to have periodic meetings via teleconferencing, discussions and decisions should not be happening in those calls - they should remain on the mailing list. WG mailing lists are meant to help coordinate the WG's operation without polluting the main RISE TSC list. Usual topics are RISE project prioritization, RISE project scoping, tracking and long term planning. The lists are not meant specifically as an additional place for technical discussions, where these would duplicating existing resources available to upstream projects.

Everything is done through https://groups.io/groups. In fact, you can even read and post message through the web interface if you don't want to see it in your regular inbox.

Check your spam folder if you don't see messages.

Participation should be limited to RISE members.

Work Group Meetings

Meetings and their cadence is at the discretion of each Work Group and its lead. Meetings can be a useful tool, but mailing lists remain the primary communication tool between the WG members.

Check the individual WG page for more info.

Also see TSC Meetings for some helpful info on getting access to recordings, resending invites, etc.

Work Group Leads

Leads are responsible for:

  • Identifying and prioritizing projects, by de-duplicating and analyzing input from all WG participants.
  • Lead necessary project scoping activities, where this helps RISE to appropriately staff/fund projects.
  • Leading WG participants in maintaining project info on the RISE wiki (not doing all the work themselves).
  • Leading WG participants to track ecosystem, build bridges with relevant upstream and external communities.
  • Regularly collect and report to the TSC project status, progress and challenges on a monthly basis. Don't assume WG members to be proactive.
  • Helping direct new member engineers who wish to participate in these areas to the appropriate project leads.
  • Helping build consensus around implementation approaches when possible.
  • Working with other WG leads where dependencies or commonalities exist.
  • Keeping the WG list "warm", engaging WG members to build a sense of community and participation. A "dead" WG mailing list is major warning sign to the TSC and the Board.

Each WG generally commit ~2-4 hours per week, probably averaging to 2hr or less. The goal here is to provide an organizational backbone for the WG, not be a proxy for every activity, so the effort is not supposed to balloon with the amount of participants, projects, etc.

WG Leads are also responsible for presenting to the TSC and RISE Governing Board on a quarterly basis, please see RISE WG Update Schedule for more information.

Work Group Project Submission

Anyone can submit a project by reaching out to the WG mailing list.

Let's say you've identified a dependency that belongs in a different WG. Hit up the WG spreadsheet.

Is the project listed there?

  • Yes. Is it prioritized?
    • No - Send email to WG list identifying as being dependent, requesting project to be selected.
    • Yes - Update the project wiki page adding yourself as a dependent project. Update YOUR project page listing the dependency.
  • No. Send email to WG list asking for project to be added (by lead) to spreadsheet (and be prioritized). Follow up with the lead.

Work Group Project Prioritization

Projects selected by Work Groups meet the following criteria:

  1. In alignment with the upstream project roadmap, goal, etc.
  2. In alignment with RISE member goals.
  3. Are either:
    1. Already contributed to by a RISE member and require additional resources (developers, reviewers, testers)
    2. Gaps that need a level of investment (e.g. into design/implementation), where a concrete focused effort by strongly-interacting (WG) participants would be more efficient than some eventual convergence by a group of weak-interacting (upstream project mailing list)
    3. Proof of Concepts (e.g. from RVI spec work) that need to be matured into upstream.
    4. Projects that are necessary to unblock RISE efforts in other area.

Algorithm of prioritizing projects is at the discretion of the WG, but all choices are reviewed and confirmed by the TSC, and subject to the Board's approval. Projects currently appear to be chosen by impact (which somewhat correlates to member interest in the project proposal).

  • No labels