-
Notifications
You must be signed in to change notification settings - Fork 30
Proposing New Features
Cloud Foundry uses a light-weight process for designing and proposing new features and functionality. The recommended approach is to post to the mailing lists before you start. The email proposal should include a corresponding design document that allows for collaborative comments. Filing a github issue on a GitHub repository is alternate mechanism which will creates a story in the team's tracker, but not as many people in the community follow the GitHub issues as the mailing lists, so for maximum visibility we recommend posting to the mailing lists.
The process we use to develop Cloud Foundry projects puts the responsibility defining "the what" on the Product Manager for each team. Before starting work on a new feature, in order to have it have a high chance of it being accepted without issues or surprises, it is essential to work with the Product Manager in advance to get their alignment and buy-in for the "the what". If an agreement is reached the Product Manager for "the what" for a new capability, then the Product Manager can arrange a discussion with the development team that owns the repositories in question for a discussion on "the how" for the contribution. This may include details on how the code should be structured. Examples of things the development team may be very opinionated about include design patterns, tests, how much to contribute with each pull request, using a feature branch vs master, using feature-flags, how to expose configuration and more.
- No need to ask permission - if you want to make an edit or add a new section, just do it!
- The official cf-docs maintainers cherry-pick content from this wiki for the official docs
- The contents of this wiki are in no way endorsed, maintained or supported by the core Cloud Foundry team
- Development Process
- Mailing Lists & Chats
- CI and the Commit Pipeline
- Contributing Code or Docs
- Contribution Standards
- Design Documents
- Proposing New Features
- Adding New Services
- Project Incubator
- Reporting Security Vulnerabilities
- CFF vulnerability mgt
- CAB meeting minutes
See CFF official project list.
Roadmaps are reflected in pivotal trackers. Tracker Instructions and steps to watch stories. Here is a flat list of all trackers:
- BOSH
- BBR
- CF Abacus
- CF App Autoscaler
- CF Buildpacks
- Concourse roadmap, and milestones
- CF Containerization/quarks
- CF Container Networking
- CF CAPI
- CF API K8s Evolution
- CredHub
- CF CLI
- CF CLI V3 acceleration
- CF Diego
- CF Docs
- CF Eclipse
- CF Eirini
- CF Flintstone
- CF Foundation
- CF Garden
- CF Greenhouse (windows)
- CF GrootFS (aka Garden RootFs)
- CF Identity (aka UAA)
- CF Infrastructure (incls BBL)
- CF Java Buildpack
- CF Java Client
- CF Lattice
- CF Logging and Metrics
- CF MEGA (Release Integration)
- CF Networking - CF K8S
- CF Networking - CFAR Mesh
- CF Mysql (core services)
- CF Notifications
- CF Permissions
- CF Persistence
- CF Postgres-release
- CF Runtime OG
- CF Routing
- CF Routing TCP
- CF services API (aka SAPI)
- Cloud Service Brokers (by SAPI/service enablement team)
- Kubo
- License Finder
- BBR
- Buildpacks
- BOSH
- BOSH CPIs
- Cf Java Client
- Core services (mysql) - repo
- Garden
- Grootfs
- Infra/tools
- Java Buildpack
- Kubo - repo
- Loggregator
- Persistence
- Release integration - repo
- Routing
- Runtime - repo
- Service API (aka SAPI)
Maybe other CIs hosted on cf-app.com are mentioned in slack ?
- See Client Tools on docs
- 3rd Party Compatible Apps