It’s been a while since my pull request to Generator-Office for Vue template has been made. I can see that my pull request now has some conflict, after the master branch received new merge from others.
While working on Office Add-ins generator using Vue, I made some modification in index.ts between line 294-295. I added action to copy 3 dot files: .eslintignore, .eslintrc.js and .postcssrc.js. My feature branch vue-template is based on version 1.1.16 . Since my changes to index.ts is now superseeded by other changes, then git unable to decide which changes should be preserved, removed or combined.
I started to realise that the way I wish to integrate advanced customization to generator-office creates a tightly coupling solution.
- The community (me) creates pull request to the original/official source in order to add new feature through pull request.
- Maintainer will then has the responsibility to maintain update to that new feature from the point of merging to master branch.
- Other contributor might be impacted by the way of how new feature has been implemented (though it has been reviewed, by reviewer).
- Pull requestor might see conflict because the changes has not been merged and superseeded by other contributor’s merging action.
Ideally contribution should not add new obligation
We can’t expect ideal situation in every possible scenario, however ideally a contribution to open source such as generator-office, should not add new obligation to the maintainer. Ideal contribution should solve the problem or enhance the way how open source has been implemented without creating new obligation.
Adding new feature which has never been in the roadmap, will create new obligation for the maintainer to ensure its supportability, patches etc. Hence as community we should not create pull request to add new feature which never been in the roadmap. A bug fixes, issue fixes, typos, logic enhancement, security patches, etc., are examples of ideal contribution that community
|Contribution without new obligation||Contribution with new obligation|
|– bug fixes|
– issue fixes
– typos fixes
– logic enhancement
– security patches
– feature in the roadmap
|– new feature not in the roadmap|
The needs for new feature or enhancement from community will always exist. However how can the new feature from community co-exists with the official product?
Today I will start an open source project Generator-Office-X, where Office developer like me can add our own recipes, our own templates based on the official templates.
We will use Yeoman’s composability feature to further modify official template, with our template / recipes. Imagine following flow to create Office Add-ins with Vue:
- Generator-Office-X prompts the user to choose Vue from selection
- Generator-Office prepares the scaffolds (composability)
- Generator-Office-X-Vue continues to complete the scaffolds (composability)
This approach will make loosely coupling solution between official maintainer of generator-office, and template generator author in the community.