Create panopoly organization on GitHub and update tests/documentation

I'd be fine with making an "official" Panopoly organization on GitHub, rather than keeping the code in @lsolesen's GitHub account. However, I'm not crazy about using pull requests as a way to submit patches to Panopoly.

I've contributed to a number of Drupal projects that do their development via GitHub (for example, Open Atrium) and there are a couple of things I don't like about it: (1) it creates extra work for the maintainers, and (2) it splits the community between Drupal.org and GitHub.

I'm more worried about #2. In the Open Atrium community, I've seen people file bugs for things that were already reported and fixed on GitHub - but they didn't see them because there was no issue on Drupal.org. Also, people in the Drupal community know how to apply uncommitted patches to their code to fix issues - they don't necessarily know how to apply a pull request to their local install. And if someone wants to put a Panopoly patch in their distribution's .make file, it HAS to be a patch on Drupal.org in order for the packager on Drupal.org to build it (it'll refuse to build if any patches are from other sites).

So, even if we have an "official" repository on GitHub, I'd prefer NOT to accept contributions as pull requests. What does everyone else think?

My vote is to keep the issues in the drupal.org issue queue and continue to use the standard Drupal patch workflow at least until (and if) the Drupal community decides to move everything to github. I love github and we use it for all of our own projects, but this is a community project and we need to stay where the community is.

@lsolesen: The thing is we still need the patch uploaded to Drupal.org in order for other distributions to pull them into their .make files. Several distributions have used Panopoly patches before they were committed (myself included! I tend to put any upgrade patches into MVPCreator to get some testing before committing them in Panopoly). So, then in addition to a pull requests, you'd have to also post the patch which just seems like double work.

@mrfelton: Yeah, I also use GitHub on lots of non-Drupal (or non-public) projects and really dig it. :-) But I absolutely agree with you - as an Open Source Drupal project, we're better served staying within community expectations.

Since we have 2 out of 3 maintainers in agreement, I'm going to strike out the bits about pull requests in the issue summary. However, making an "official" GitHub repo for the Travis-CI tests is still something we could do!

I've gone ahead and created a "panopoly" organization and added Matt and Tom as owners:

https://github.com/panopoly/panopoly

I pushed the latest code there, but there's still two things to do:

• #2229003: Make behat.travis.yml not care about repository owner
• Update maintainer documentation

I've setup the Travis-CI stuff for the new panopoly/panopoly repo on GitHub and updated the maintainer docs.

@lsolesen: Can you remove the write permission that myself, populist and mrfelton have to your repo? That should make sure that we all switch over to the repo. :-)

Sweet, thanks!

Yeah, that's because the .travis.yml from the main repo specifies the Panopoly mailing list. I'm not sure what we can do about that other than removing the mailing list from the main repo. :-/