Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 9.69%. Comparing base (1bb7314) to head (126fa9c).
⚠️ Report is 114 commits behind head on develop.

@@             Coverage Diff              @@
##             develop   #5652      +/-   ##
============================================
+ Coverage       9.12%   9.69%   +0.56%     
- Complexity      1170    1319     +149     
============================================
  Files            701     717      +16     
  Lines          45281   45778     +497     
  Branches       10851   10926      +75     
============================================
+ Hits            4131    4436     +305     
- Misses         40497   40656     +159     
- Partials         653     686      +33     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@ewaterman @awalkowiak

What are your thoughts on the best place for this document?

This artifact should be public-facing and is a living document (proposal, discussion)

The options are:

• Project root (current PR) - doesn't seem to fit here since it's a living document at the moment
• RoadMap (https://openboxes.com/roadmap/) - doesn't really fit here but wanted to provide the link
• Official Documentation (docs.openboxes.com) - maybe some day
• Contributor Guide (https://openboxes.gitbook.io/contributor-guide/) - probably not here
• Community Forum (https://community.openboxes.com/) - i like this option because it hits a larger audience
• GitHub Discussions - make sense here since the audience is more deverloper-oriented. discussion happens here until we want to take action and then perhaps we create an ADR based on decisions made
• ADR Repository (docs/adr or a separate ADR repo) - eventually, the decisions we make should go here

I forgot two other options, but these might not be valid at the moment for the reasons expressed.

• Confluence PIH - not public facing
• Confluent OpenBoxes - no one really uses it at the moment

I think my recommendation (unless and until we create a project / tickets for this work), would be to move the discussion to Discourse (community.openboxes.com) so more eyes see it and provide feedback or GitHub Discussions since it's a developer proposal / discussion at the moment.

And then if we actually standup an ADR repo we can create separate ADRs for each decision we need to make so there's a record.

cc @mdpearson

Some more thoughts. I think there's a state machine here that would be cool to implement with respect to these types of proposals. This isn't just a random idea I had one day. It's been brewing for a long time, but I haven't had time or budget to work on it.

See the Opporuntity Backlog (challenges, opportunities) that I created a few years ago.
https://docs.google.com/spreadsheets/d/1DDt58XYPdmWbnWeYnrZTLntb4RVIRBAJd4VercP1OYI/edit?usp=sharing

The challenge is listed in the following document re: Challenges > HRDL-015 Scalability and there are a few opportunities mentioned in the Opportunities tab

• REF-008 Quartz clustering configuration PoC
• REF-009 Stateless API
• REF-010 Session Replication
• REF-100 Database per tenant multi-tenancy

I realized recently that we probably need to make some incremental progress on the horizontal scaling challenge because we have a few implementations that might eventually reach limits re: vertical scaling.

This Opportunity Backlog also probably needs to be public-facing (separate repo?) to track all of the challenges we've identified. These could live in GitHub issues but given how much work Evan has done cleaning that issue tracker, that's probably a bad idea. I think there could one place for identifying / tracking the challenges and opportunities (like the Google Sheet) and another when we promote that idea to be implemented.

So here's the potential flow for all of this:

• Document the "challenge" that we face (see Challenges tab)
• Create an Opporuntity Backlog item that might require discovery / discussion
• Promote to a Roadmap Item when we think we might be able to start thinking about the opportunity
• Create a Discussion in Github Discussions or Discourse (what we currently have here)
• Create a Detailed Proposal to detail the scope of each issue (should try to limit this to each challenge)
• Create any Decision Records (ADR) for each decision that we need to make
• Add Product / Technical Roadmap Item (confirmed MVP scope) to show progress
• Create a GitHub project / issues for the scope of work to be implemented
• Update the Roadmap Item (include status, version, last updated, link to proposal or project depending on status)

GitHub Discussions since it's a developer proposal / discussion at the moment.

I agree that anything that is technical and still in the discussion phase should be a github discussion so that it is persistent somewhere and we can involve the community.

As for how to handle the discovery & documentation process, I'm not sure. We don't really have a process for larger community efforts like this.

At PIH we'd (ideally):

1. have an idea for a larger project/challenge that we want to work on
2. document that somewhere (in idea garden or just in our personal notes)
3. discuss with the team during release planning and decide that we want to do this
4. create a discovery ticket in an upcoming sprint to track the initial work
5. do the discovery and create a discovery document in the confluence outlining the findings
6. present the findings to the team and if we're all in agreement, create an epic with tasks to address the tasks uncovered by the discovery

So we could do something very similar here, just with github issues.

I agree that we have lots of potential challenges that would flood the github issues if we ported them all over so until we plan to actually do something about them we should probably keep them in a doc somewhere. I like the idea of having the following doucumentation sources:

• mkdocs -> for people who want to run openboxes. For admin users, not the wider community and not for contributors.
• gitbook -> for contributor guides (code and otherwise)
• non-PIH confluence -> for fluid project management. Documents, discoveries and decision records

So:

1. have an idea for a larger project/challenge that we want to work on
2. document that in the confluence somewhere (in an idea garden / challenges backlog) and/or create a github discussion thread to talk through the idea publicly
3. once we decide that we want to address the challenge, create a discovery github issue
4. do the discovery and create a discovery document in the confluence outlining the findings
5. discuss further in the discussion thread if needed then create an epic in github with issues to address the individual tasks uncovered by the discovery