I like it +1.
The BPs can then be used as a basis for documentation, and they can be held open until all documentation for a feature is done. -Ivan On Wed, Nov 22, 2017 at 9:30 AM, Sijie Guo <guosi...@gmail.com> wrote: > Hi all, > > I have been thinking of how to improve documentation process for a while. > We have a good BP process for introducing enhancements, features. However, > this process is not well integrated with our review process, and the > content of a BP is not used for documentation. > > I am proposing moving the BPs from wiki to github for a couple of reasons: > > - the ASF cwiki is disconnected from Github, and usually becomes out of > date quickly. It doesn't really catch up with the code changes. Most of the > content (documentation, contribution/release guides) are already in > website, cwiki is only used for tracking BPs and community meeting notes at > this point. > - Moving BPs to github will leverage the same github review process. So > people are easier to review and comment on BPs. > - The BPs can be finalized and used for documentation. > > Here is the rough idea: > > - BPs are maintained under `site/bps` directory. > - If a developer is making a BP, he can create an issue and send a pull > request for the BP. > - Once the BP is reviewed and accepted, it will be merged and listed as > `Accepted`. > - The original BP issue will be left open during its development. Once the > BP is fully implemented and merge, we update the BP as done when closing > the BP issue. (This probably can be automated with github webhooks). > > If we put BPs in `site/bps` directory, the BP will be available on website > once it is merged. so the BP can be also updated along with code change, > and make the implementation and documentation in sync. > > Also, If we can make BP process work on Github, we can deprecate using the > ASF wiki, make it a pure github workflow. > > I would like to hear your opinions about that. > > - Sijie
