I put up a PR for this idea: BP-20: github workflow for bookkeeper proposals.
https://github.com/apache/bookkeeper/pull/760 This is my staging website, to show how the bookkeeper proposals would look like there. https://sijie.github.io/bookkeeper-staging-site/community/bookkeeper_proposals/ https://sijie.github.io/bookkeeper-staging-site/bps/BP-20-github-workflow-for-bookkeeper-proposals/ I think it would make discussions and comments easier on a PR. please take a look and let me know your thoughts. - Sijie On Wed, Nov 22, 2017 at 3:42 AM, Enrico Olivelli <eolive...@gmail.com> wrote: > Il mer 22 nov 2017, 10:44 Sijie Guo <guosi...@gmail.com> ha scritto: > > > On Wed, Nov 22, 2017 at 1:35 AM, Enrico Olivelli <eolive...@gmail.com> > > wrote: > > > > > We could try with the next BP > > > Maybe we'd better do the the migration of existing docs only after > seeing > > > that the approach is feasible. > > > My major concern is about non-committers > > > > > > why non-committers is a concern? Non-committers can still create a github > > issue and send PR, no? Current BP process requires people to create ASF > > wiki account and also committers to grant wiki edit permissions. It > > requires more steps for people to propose BP. > > > > Yes. Ok for me > > > > > > > > . > > > Anyway who proposes a BP will likely be the lead for the > implementation, > > if > > > he is not a committer he would be somehow skilled and can manage to > > > integrate with the flow > > > > > > -- Enrico > > > > > > 2017-11-22 10:30 GMT+01:00 Sijie Guo <guosi...@gmail.com>: > > > > > > > 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 > > > > > > > > > > -- > > > -- Enrico Olivelli >
