plombardi89
commented
6 years ago @rhs and I spent significant time on 2018-05-03 discussing and whiteboard through this task and we have a plan now. What we realized is that "design the extensibility mechanism" isn't quite possible yet though we have a rough idea of how to do start. The output from the meeting was this:
-
Open a PR against Forge to begin clarification of the user roles and stories that guide Forge development now and in the future.
-
Identify the execution stages and goals of those stages in Forge today and then draw up how those individual pieces can be turned into standalone components.
-
Based on the identified bits from <2> develop a future model of extension around the stages and goals. This is basically identifying the hooks and interfaces that can be modified, added to, removed from etc as an end user.
-
Spike on an incremental path to move Forge from a single monolithic code base to a more modular code base. The idea is to tease apart the system using the information from <2> to create individual programs (likely in Go) that perform the operations and then invoke them from the existing Forge CLI. This is an incremental step.
-
Spike on a mechanism for extension. This is about developing a consistent interface and mechanism for users to change the execution goals for Forge to suit their needs.
Users would like to customize the behavior of Forge. This is very difficult right now because Forge has very limited extensibility options.
We need to do the following: