# Knative Function Task Force Goals

This document outlines the intended goals for the Knative Functions Task Force. Some of our goals will be simple and straightforward. Others may be complex, or involve architectural or procedural decisions that neccesarily mean work cannot start immediately. In this document, goals are categorized in this way: Needs Discussion and Needs Action.

## Goal Completion

Goals should specify a completion condition or exit criteria that is achievable and measurable. A Task Force is meant to have a finite lifespan and solve a specific problem or set of problems. When the Functions Task Force has completed its stated goals, it should be dissolved.

## Needs Action

### 1. Move `func` repository to `knative-sandbox`
The `boson-project/func` repository needs to move to the `knative-sandbox` organization on GitHub. Additional repositories, such as `boson-project/buildpacks` will remain in the `boson-project` organization for now. The repository will need to be configured for peribolos and prow (and any other standard Knative CI processes that I may not be aware of).

**Exit criteria**
* `knative-sandbox/func` exists
* Git history is preserved
* Issues and pull requests are transferred
* CI processes are configured and functional
* Integration with prow and peribolos is completed

### 2. Copy existing Boson Feature Track documents to Knative FT format
The Boson Project currently has a number of Feature Track documents for planned and in-progress development. These should be modified to conform to the Knative Feature Track format, and presented to the community for adoption. In some cases, where development work is already ongoing and near completion, we may choose to simply make the existing document public, but not require approval.

**Exit criteria**
The following, existing feature track documents should be converted and potentially presented to community for approval.

~~* On cluster build~~ ==OUT OF SCOPE==

* Extensible templates (aka language packs)

### 3. Extensible Language Packs Gap Analysis
The current capabilities of the `func` project already provide a rough extensibility capability, and there is ongoing development in this area (see also the Extensible Templates Feature Track noted above). The Task Force should document what vendors can do today to provide their own language packs/extensions, and identify any requirement gaps between what has already been planned and what is ultimately desired.

**Exit criteria**
* Current method for providing custom language packs is documented
* Gap analysis between current capabilities and desired state is complete

### ==(OUT OF SCOPE)== 4. On Cluster Builds Gap Analysis
Create a plan to move forward with implementation of on-cluster builds. The Boson project has existing plans for this work (see also the On Cluster Builds Feature Track noted above). The Task Force should identify requirement gaps between the current Boson Feature Track and the desired state.

**Exit criteria**
* Gap analysis between current plans and desired state is complete

### 5. End-User Research
Identify a few research questions, an interview script, and a timeline for end-user interviews conducted by the UX WG.

**Exit criteria**
* ID'd Research Questions
* Script written
* User interviews scheduled

## Needs Discussion

### 1. Determine baseline community builders, buildpacks, and templates
The current builders, buildpacks and function templates, referred to together as language packs or language extensions are based on Red Hat's UBI8 container images and may include bespoke invocation frameworks or opinionated runtimes such as Quarkus. These builders and buildpacks are not moving to the Knative sandbox along with `func`. For the immediate future, however, the dependencies will continue to exist. This Task Force should identify what the community version of these will look like, and create a transition plan.

**Exit criteria**
* Have a development plan that includes
* One or more builder images based on a vendor neutral OS, for example Alpine
* Buildpacks for Node.js, Python and Java (complete set of runtimes TBD)
* Project templates for each supported language/runtime
* A place to publish these images (possibly gcr.io/knative-sandbox?)
* A plan in place for an initial MVP that includes one language pack
* Potential external dependencies, such as invocation frameworks or runtimes have been identified
* Resources such as GitHub repositories that contain the source code for builders and buildpacks have been identified and created if needed

### ==OUT OF SCOPE== 2. Invoker Contract
In order to enable the most widespread adoption across enterprises, a standard API contract should be codified. At the core, this means the function signature; its name, invocation parameters and return values as well as types and any enabling APIs. In doing this, we enable function portability across multiple vendor-provided language extensions. There is a lot here, spanning multiple languages, and the task will take time and collaboration from multiple interested parties. The Task Force only needs to establish a plan to make this happen.

**Exit criteria**
* Stakeholders are identified
* Plan is in place to execute

### ==OUT OF SCOPE== 3. IDE Integration
Determine what level of interest there is in the community to provide IDE integration with VSCode and possibly IntelliJ.

**Exit criteria**
* User surveys produced and applied
* If there is sufficient interest, a plan for initial design and development

### 4. Determine Processes and Procedures
Determine and adopt standard processes for handling issue triage, pull request approval and merge, periodic releases, versioning, etc.

**Exit criteria**
* _

### 5. Is `func` Just a Plugin
There are a lot of parts to Knative functions, and it could be more. Do we try and answer what that "more" could be as a part of this Task Force?

**Exit criteria**
* A "vision" document articulating what the Task Force sees as the future for Knative Functions

### 6. What Happens When We've Achieved All of the Above?
Where do we go from here? Is a Working Group formed or do functions remain under the purview of `kn` indefinitely.

**Exit criteria**
* If we determine that `func` is more than just a plugin, the vision document will be the prerequisite for the creation of a Working Group.