Currently

Browse

Knowledeg Bases

QA

Package Snapshots

Administration

Browse and Knowledge Bases are for "repository" managment. They store artifacts and allow you explore and to edit artifacts.

"Browse" allows you to search per category and "Lnowledge Bases" by package a .pkg. .pkg are deployable units

QA shows analysis reports and allows for testing of a package.

Package Snapshots allows a specific Package version to be exposed under a named url.

Administration is for setting preferences and settings for Guvnor

We need to rethink things from an end user experience. A user always has a goal in mind, what is it they are trying to achieve, how can we represent things in a way condusive to that. What role does the user need to assume for that step in the goal. for example

• Exploring knowledge to see how it's used across projects
• Authoring generic rules that other projects might consume
• Authoring a project itself and knowledge it contains
• Deployment
• Runtime inspection and managmen
• Dashboard
  • information dashboard
    • What Knowledge has Changed
    • What tasks are waiting on me
    • Other watches
  • wizards "what do you want to do"
    • see intellij opening screen for how it "guides" you
  • mixing of the two
    • might want ot add most common tasks and information onto one screen
• Repository
  • Browsing
    • Everything is an artifact, from individuals rule sand processes to project collections of artifacts and working collection of artifacts.
    • It should allow easy exploring of dependencies and relations. [Jervis Liu] Currently we have the concept of Global Area, this area is designed for artifacts that can be reused across various projects/packages.
    • It should even be possible to relate projects if they interact with each other
    • Should help get an understanding for the flow of knowledge
  • Refactoring
    • refactoring probably needs to be done at a global repository level, rather than at a project/working set level.
      • Once refactored it's a new version
      • Wizards to find out what depends on the old version and to migrate
        • Should have "reports" of artifacts that depend on older versions, so that this migration can easily be done at a later time and not forgotten about.
  • Reporting
    • Should be able to make custom reports, which artifacts use which classes or fields etc.
    • Usage reports
    • Change impact reports
    • Should have built in default set of "warnings" like untested code or potentially bad code or areas that need attention. This should be live and continously updated as knowledge changes. Can also include things like "someone has updated an artifact you depend on, do you want to update". Everything that is needed to try and keep a healthy collaborative knowlege base.
    • Expose reports via dashboard or other mechanisms
  • [Jervis Liu] Query/search
    • More advanced support to search and query, probably allow using SQL style queries.

    • Allow users to search based on custom tags etc.

    • A query can be saved. This can be used for following purposes:
      • The query result can be used as user customized view.
      • The query result can be used to serve KnowledgeAgent (through workingset) or serve other third-party applications through REST interface
    • Serve as a feed. Users can subscribe to the feed to get notification on any changes.
  • [Jervis Liu] Expose repository through remote interface.

    • provide "feeds" for people/systems to monitor for changes: For  example,  user subscribes to a feed which lists contents of package or  user  subscribes to feed which lists changed contents in a package

    • 
      provide the default remote api to push/pull content and meta data from   the repository. This allows other applications to integrate with Guvnor  by accessing repository programmatically.

• Authoring
  • Individual pieces of knowledge
  • By Project

  • Related Sets

    • Working on processes or rules that themselves not deployed, but others might consume them as part of their projects.
      • Knowledge Set/Working Set
  • Collection of projects
    • distributed projects that interact with each other, but I want to author in the same workspace.
  • We need to put a lot more thought into the above 3, about how knowledge is collated in response to how a user wants to view it
  • [Jervis Liu] More advanced role based authorization and role based views: The ability to limit what a user sees in GUI.
  • A user will want to be able to make their own "boomarks" for projects, knowledge sets etc that they work in.
    • Navigates to that set, tabs opened for that set are preserved.
      • Needs to have the concept of Workspace and "nested" workspace.

• [Jervis Liu] A user can add additional application based "tag" information to rules/projects/knowledge sets etc. Lets call it metadata. The ability to have customized metadata is crucial for configuration, query, lifecycle management etc.
• Simulation and Testing
  • Just another artifact
  • I think each collection of knowlege, be it project or knowledge/working set will have associated simulation/testing artifacts.
• Life cycle and status
  • Knowledge should follow a life cycle. Such as the original author creates it (draft), then another author reviews/updates it (final), then it's submitted for release (release) and someone else actually releases it (released). We'll need to carefully think about this life cycle and the status involved, to a certain degree this probably needs ot be user configurable, everyone has their own way and terminology. It can be driven by task managment too.
    • Some statuses will drive other "roles", such as marking something for deployment means that from the operations view someone can now physically deploy the knowledge.
    • The wizard could actually move someone to the deployoment perspective. Such as how eclipse will offer to move you to the debug perspecetive when attempting to debug. This way it makes it quick to go from marking something as ready to deploy to actually deploying (assuming you have permissions).
    • [Jervis Liu] Lifecycle management can be integrated with work flow.
• Operations
  • Deployment
    • The act of updating the runtime's knowledge definitions.
    • Users mark stuff to be "deployed"
    • In general the "workspace" maps to a runtime. We have to be able to handle initial new deployments and updates.
    • A deployment JAR should be used to package, and compile if necessary, all assets in the artifact.
      • META-INF or equivalent is needed to preserve the urls (version and location) for any used assets, so that we have tracability and "polling" for updates, if needed.
      • The JAR is really just a cache of the assets, to save the application pulling each asset individually from guvnor as it does at the moment. It should also make transparantly loading from guvnor, while restarting from stuff on disk, possible.
    • [Jervis Liu] A user can view the structure of operation network (assuming have such permissions). On which physical server and which container an instance of Drools runtime has been deployed, what its configuration is etc.
    • [Jervis Liu] A user can add/remove/update Drools runtime in the network.
  • Runtime Management
    • [Jervis Liu] The ability to show runtime information of Drools, such as memory usage, log, how many rules have been fired etc. 
    • [Jervis Liu] Change configuration on the fly.