Jeffrey Ryan Thalhammer

I like the idea of doing this. Perl 5 has gotten easier to contribute to over the years, but this would make it even easier.

That said, the core is still going to be an impenetrable mass of C and macros, which is probably the biggest barrier to entry for many types of improvements.

Hey, cool! I like this idea. I'm not sure if I'll ever contribute a line of code to Perl's core, but if I do, this'll make my life easier.

The problem I see is that new code should come in via a smoke-me branch, and I'm not sure if there is an easy way for a project administrator to take a pull request on one branch and pull it in to a new branch prefixed with "smoke-me". I would love to see this sort of development style incorporated into PDL, so if you find a set of steps to make this possible, please post them somewhere so we can use them, too! :-)

An amazing alternative would be to find or develop a mechanism for adding github pull requests to the smoke queue. Then again, somebody could put arbitrary code into a pull request, so maybe automating that sort of thing would introduce a security vulnerability for the smokers... OK, maybe it would be good for the p5p to add other users' repo/branch to the smokers after they've had a chance to look over the change set. What do you think?

This would make it much easier for the casual, drive by fix, especially to the non-code things.

I'm sure there's some special magic that p5p gets out of hosting their own git server. If someone lists what special hooks and so on it uses, another person can probably be able to figure out how to do it in GitHub so p5p knows they don't lose anything.

And, maybe someone will adapt perlbug to use Github issues as a proof that it can be done. I know `/anick has done similar things, but using non-core modules too. With the recent discussion about perlbug, maybe there's the political will to bring it into the present now. :)

I feel the real let-down of github issues is its very weak on metadata vs RT. Metadata tools are limited to tagging and milestones, and thats basically it, and for seriously large projects this gets seriously out of hand.

ie: https://github.com/CPAN-API/metacpan-web/issues?state=open

That said, I'm moving all my bugs to it, because its just more convenient.

Howdy, I've actually done a good deal of work getting a separate git repo posting to github via a post-receive hook (@ SocialFlow.com), and was planning on doing some work with regards to syncing pull requests and maybe some other stuff?

Anyhow, the important bits are in this Makefile: https://gist.github.com/ediblenergy/4950549

the idea being that github_mirror@yourserver has keys to the repo, and git@private-git-host has keys to github_mirror@yourserver.

We've been using this to keep a sort of 'read-only' repo up to date.

I know there was a project that imported their entire bug-report database into GitHub. ( may have actually been Rakudo )

For casual drive by fixes to non-code, we already have the perl-doc-cats github organisation that took over maintenance of perlfaq when brian quit. I'd love to see that publicised more.

For code fixes, these are going to need to be discussed on perl5-porters anyway - and it's already an open access mailing list, so I don't see that as our primary accessibility problem.

Discussions inline with code happen via "putting a patch in an email" - it's a pretty usable approach, and works fine for a lot of people.

Notably, it works fine for the people already contributing, who're the people who can provide enough help to get this stuff ready.

I'd be fascinated to see a two way gateway between github pull requests and perl5-porters - that way the github generation could interact in the way comfortable for them, while still allowing those of us who work better via email to continue to do so.

To be entirely honest, I think the key obstacle to -code- contributions is that it's quite hard to get an overview of the project - there's no "map" as such that lets people figure out where to look for what. I'd love to see such a thing - for the sake of argument call it 'perlsourcemap' - and that would, I think, lower the barriers to contributing substantially more than "now you can click on a web UI rather than posting to a mailing list".

So, in summary -

(1) perl-doc-cats already exists on github for non-code contributions, so please support that rather than duplicating the effort

(2) working on a perlsourcemap would, in my opinion, help lower the barrier to entry more than any tooling change would

(3) allowing the existing mirror to accept pull requests would be interesting -provided- they can be two way gatewayed to the mailing list so that existing contributors aren't forced to use github

(4) syncing to issues is probably less important; our problem isn't people being able to comment on bugs (perl5-porters already has plenty of people who comment but never actually contribute), it's getting more people to contribute, and that means making writing patches more accessible more than it means making submitting them more accessible

(5) please, please rename the perl organisation you created to something else (thaljefs-fascinating-and-cool-experiments would be fine by me ;) because it's making this come across as a backseat driving exercise and while I know that's not your intent, the rest of the world doesn't

(6) perl-doc-cats. perlsourcemap. pull requests. in that order. I tell you three times! :)

(and, thaljef, much love for the fact that you're not saying "other people should do this" but instead "if I can figure out what should be done, I'll try and do it" - no matter what the rest of the outcome, we need more people with your attitude!)

-- mst, out

For the lazy: https://github.com/perl-doc-cats