Skip to content

Advise against maintaining a fork in the README.#9607

Closed
cjcenizal wants to merge 1 commit intoelastic:masterfrom
cjcenizal:chore/document-forking-policy
Closed

Advise against maintaining a fork in the README.#9607
cjcenizal wants to merge 1 commit intoelastic:masterfrom
cjcenizal:chore/document-forking-policy

Conversation

@cjcenizal
Copy link
Contributor

@cjcenizal cjcenizal commented Dec 22, 2016

@cjcenizal cjcenizal force-pushed the chore/document-forking-policy branch 2 times, most recently from 1643d5e to e72d1f0 Compare December 22, 2016 05:52
@epixa
Copy link
Contributor

epixa commented Dec 22, 2016

This seems like a huge amount of content to dedicate to something that's mostly a non-problem for us and our users at this point. It is rare for someone to fork Kibana without realizing the challenges and then asked for our help or support for it. I suspect the vast majority of people reading our readme would not find that section relevant at all, so at the least I think this is the wrong place for it.

@cjcenizal
Copy link
Contributor Author

cjcenizal commented Dec 22, 2016

@epixa That's a good point Court. I think it's important we surface this in the README, but at the same time I agree that we don't want to bloat this top-level document. How about we move the bulk of this information into CONTRIBUTING.md and link to it from the README?

@epixa
Copy link
Contributor

epixa commented Dec 22, 2016

It kind of seems like an anti-contributing concern though, no?

@cjcenizal
Copy link
Contributor Author

@epixa Haha, I guess so. Thoughts on the best place for it?

@cjcenizal
Copy link
Contributor Author

Also, I'm not sure why the tests are failing. Investigating now.

@cjcenizal cjcenizal force-pushed the chore/document-forking-policy branch from e72d1f0 to 40c30bc Compare December 22, 2016 17:48
@rashidkpc
Copy link
Contributor

I'm with @epixa on this one. This doesn't belong in the README.

Given the anti-contributing nature of it, I don't think a statement of this nature belongs in the repo at all. No one wants to maintain a fork, its a last resort. Adding this to our docs won't change that. Our best defense is a powerful, flexible plugin architecture that alleviates the need for forking and promotes contributions to a welcoming ecosystem. Helping users get started with understanding it is a better path.

@kevinkluge
Copy link
Member

What if we changed this to describe the plugin option? We can preface it with the warnings of forking and talk about how there were a lot of forks with Kibana 3 and the issues that the fork-maintainers had. (BTW, I am not sure everyone sees the pain of creating and maintaining a fork. There is a first time for everyone to do it. :) ) Then we go into how plugins could be an option, if you haven't gotten the feature/fix in a time you need.

@epixa
Copy link
Contributor

epixa commented Dec 23, 2016

Let's avoid making assumptions about people's motivations entirely and instead explain that we have a plugin system and then link to the plugin contributor docs on the website.

@cjcenizal
Copy link
Contributor Author

I chatted with @uboness and we agreed to move this to the wiki instead.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants