As far as I know the development on github mostly goes this way: If someone wants to work on your code he makes a fork of your repo and makes some modifications. Then he informs you that he has some commits there you might be interested in fetching. Also developers on githup usually check out what is done in forks of their project and fetch interesting stuff without being promted to anyway.

What you probably meant is a real fork. That is a split in development because someone wants to move the project into a very different direction, thereby renaming it. As you might have experienced yourself with Devel::Comments, this is a step that is very seldom done and most of the time only after massive efforts to either find some lost maintainer or throw around abusive language.

This kind of fork is something exceptional and usually the forker doesn't know in advance that he will fork eventually. So nobody will step up and tell you "I'm a forker" because you first would have to either have abandoned the project for a long time or (in his eyes) don't accept his contributions after lots and lots of discussions. So if there exists a forker like that you must know him already

Someone who yells at you in CB is not a critic but a raving lunatic, they usually don't want any code of yours in a 10 mile radius ;-). If you welcome their contributions just add lots of bugs and failed code to your project and CB will be full of them

To make the point in my previous post about critics somewhat clearer: There are two sorts of critics in your case:

1) The user. He has something to critizise about the user interface or features or documentation of your module. He doesn't need any source code, he is concerned only with what you distribute and its deficiencies. We can ignore him, he has no involvement at all with your code

2) The developer critic. He found some fault in your internals or misses a feature but knows how to add it. He may only use words but he looks at your source the same way as a contributor would, he just doesn't do the last step of really implementing the patch(es) but only tells you about it.

And a last point: Not only are all these different roles identical in their requirements. But anyone might, after using your module, turn up to fit any of these descriptions. He might just report a bug, think about a fix and just telling you about it or really write the fix (or feature). Nobody has identified a role to you yet because nobody can see into the future.

Okay, I think we've established that you would have the same wishes no matter which hat you wore. So, regardless of hat, which items would you want me to put in the repo?

Note: Contents may change.

Ok, I'll try to be not as evasive anymore ;-). But the point still stands that ultimately the job of assessment falls to the only person who knows where the juwels are, to you. Only you can judge if for example some test scripts are worth keeping or not

moritz answer is already 90% of what I would have to say. Normally you should not include unfinished code experiments, non-working test scripts or utilities that are only relevant to your mode of operations

BUT there are always exceptions. Your example of a test script that almost works and is useful and you just don't know how to make it work could be such an exception. You might put it in (disabled naturally) with a plea to help make it work.

Or there might be a utility script that is really useful for this module. I have no idea what that could be with Devel::Comments, but for example for a module simulating a game world it could be a fight simulator script to aid in balancing