You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Aug 12, 2022. It is now read-only.
General
Users should sign up with the intention on finding a module to use in order to solve their simpler problems.
Home page should preview featured stacks, users, and daily modules news (what are new components released into the ecosystem).
Each stack should orchestrate very clear data oriented flow to problem solutions. One example is the requirement of a basic routing model.
“Routing” searches should show basic routing solverstack available for mvp. This stack may include modules/components such as:
Location Data Processing
Node Indexing
Geocodes and Previews
Distance Matrices
Model Assumption Helpers
Have weight; no pallets
Have pallets; no weight
Ortools RPC Head
Constant Vehicles
Constant Capacities
Ortools Basic Capacitated Solve
Open Sourced RPC API Flask Service
Ortools VRP Dashboard
Intractable Visual Prototype
Stand-alone Add-on Prototype (Just redirect from Head)
Genetic Algorithm Ortools Scheduler
Constant Driver Count
Required USA Driver Regulations Adherence
Rust or NumPy Service
Gantt
NOTE: some design battles will be how to blend redundancy in UI. Example: Ortools Head is current vrp setup box. Geocoding previews can overlap with this module head. What should occur is a natural prioritization of ortools over geocoding. Maybe assign weights to modules within stack (representing order) and propagating hide vs show down it. This also ties into the peer-review-like nature of the ecosystem - where people influence stacks for iterative publishing. This can be done as a PR type process but more granular. Think discord chats but adjacent to the life of a stack. Conversation/peer review requests can be toggled into view.
Users should be able to search for a module, see it in their feed (on a stack studio page) click to add/append to stack. You can create stacks with one module or 100 as long as each are configurable. All configuration should be defined by data objects and targets.
Solverstack ecosystem can allow devs to integrate with apis and sdks. We can create solverstack object validation at integrated endpoints. If custom modules want to be contributed we can offer methods involving basic github linking for smart modules, full blown service integration, or in-app solver-lang module construction.
The text was updated successfully, but these errors were encountered:
General
Users should sign up with the intention on finding a module to use in order to solve their simpler problems.
Home page should preview featured stacks, users, and daily modules news (what are new components released into the ecosystem).
Each stack should orchestrate very clear data oriented flow to problem solutions. One example is the requirement of a basic routing model.
“Routing” searches should show basic routing solverstack available for mvp. This stack may include modules/components such as:
Location Data Processing
Node Indexing
Geocodes and Previews
Distance Matrices
Model Assumption Helpers
Have weight; no pallets
Have pallets; no weight
Ortools RPC Head
Constant Vehicles
Constant Capacities
Ortools Basic Capacitated Solve
Open Sourced RPC API Flask Service
Ortools VRP Dashboard
Intractable Visual Prototype
Stand-alone Add-on Prototype (Just redirect from Head)
Genetic Algorithm Ortools Scheduler
Constant Driver Count
Required USA Driver Regulations Adherence
Rust or NumPy Service
Gantt
NOTE: some design battles will be how to blend redundancy in UI. Example: Ortools Head is current vrp setup box. Geocoding previews can overlap with this module head. What should occur is a natural prioritization of ortools over geocoding. Maybe assign weights to modules within stack (representing order) and propagating hide vs show down it. This also ties into the peer-review-like nature of the ecosystem - where people influence stacks for iterative publishing. This can be done as a PR type process but more granular. Think discord chats but adjacent to the life of a stack. Conversation/peer review requests can be toggled into view.
Users should be able to search for a module, see it in their feed (on a stack studio page) click to add/append to stack. You can create stacks with one module or 100 as long as each are configurable. All configuration should be defined by data objects and targets.
Solverstack ecosystem can allow devs to integrate with apis and sdks. We can create solverstack object validation at integrated endpoints. If custom modules want to be contributed we can offer methods involving basic github linking for smart modules, full blown service integration, or in-app solver-lang module construction.
The text was updated successfully, but these errors were encountered: