How to mark "private" VCS in META files?

[szabgab]

I continue my fight to get more people mark their VCS in the META files: http://blogs.perl.org/users/gabor_szabo/2013/09/licenses-and-the-repository-links-on-cpan.html but I know there are a few CPAN authors who use private VCS. (or don't use at all, but let's not be judgemental).

It would be probably useful to be able to tell apart people who have private VCS (or for some other way do not want to share the link), from people who just don't know about the META field or have forgotten to update it.

Would it be possible to let those people somehow communicate this? e.g. by setting the type => 'private' ?

resources => {
   repository  => {
      type => 'private',
   },
}

[karenetheridge]

I don't see how that helps. The purpose of this field is so contributors know where to fetch the latest version of the code, and where to submit patches. Knowing the repository is private does not help the user in any way; we might as well leave the value out.

(or don't use at all, but let's not be judgemental).

That sounds to be more the problem here - people just aren't using a VCS for their code, which means it's not as open as it could be.

[rjbs]

Users can put type => 'private' in their META files to have an entry there that nobody can use. That would work.

@szabgab's goal is presumably to be able to email everyone who has a dist w/o a repo listed. This would be a way to opt out.

That said, it seems easier to assume that people won't opt out. Instead I would do this:

• send an email to each repo-less author once, giving them the ability to say "never email me about this again"
• after waiting a while to collect those responses, send them email about the second repo-less dist under their name
• repeat again, every once in a while

[andk]

Ricardo Signes notifications@github.com writes:

Users can put type => 'private' in their META files to have an entry there that nobody can use. That would work.

@szabgab's goal is presumably to be able to email everyone who has a dist w/o a repo listed.

Which some would consider spam. I hope this isn't the goal.

This would be a way to opt out.

That said, it seems easier to assume that people won't opt out.

Even easier is to assume they might already have opted out.

Instead I would do this:

• send an email to each repo-less author once, giving them the ability to say "never email me about this again" • after waiting a while to collect those responses, send them email about the second repo-less dist under their name • repeat again, every once in a while

Why on earth would you do this except when you are considering actually reading the repository and working on the code? In which case you should contact the author -- preferrably via a public bugtracker, so that the answer will be public for the time being. At that point in time it's quite a natural idea to also suggest a patch to update the repository field.

andreas

[dagolden]

I'd rather see this addressed through the Kwalitee system (negative feedback) and blogging (positive encouragement). Harassing authors about compliance with a standard seems un-perlish.

[karenetheridge]

Agreed, of all the things to mail an author about, this isn't it (at least in itself). However, I'd be interested in seeing something like a once-a-year mailout to all authors, asking if they're still alive (if we haven't seen any activity in a while), and telling them about all their Kwalitee scores for all of their dists.

[Leont]

Yeah, I'm not in favor of spamming either. Sending authors a once-per-year heartbeat email sounds reasonable to me, but that's unrelated to this issue.

[rjbs]

I think calling this harassment is unwarranted, if it stops when the target says, "none for me, thanks."

That said, I also think that there are enough people and things sending their own automated emails about stuff, and they're not generally that useful. I'd rather see something like this go into a thing you can consult, rather than a thing that bugs you.

Then the annual CPAN newsletter can just remind you of the services available to you as a CPAN author. :)

[neilb]

the annual CPAN newsletter can just remind you of the services available to you as a CPAN author.

+1

And test whether your email address has gone stale.

[dagolden]

I think calling this harassment is unwarranted, if it stops when the target says, "none for me, thanks."

If everyone who has some "best practice" they think authors should comply with emails them with individual opt-outs, the net effect is harassment by "the community":

• Your distribution failed its tests
• Your Changes doesn't comply with a spec
• Your META doesn't include an optional spec field and it should, but only to tell us you don't offer it anyway
• [add next bright idea here]

I think we should publish data about people's distributions and make it very public on places like MetaCPAN. Authors should "pull" what information they seek. It shouldn't be pushed to them. If we do push, it should be opt-in not opt-out.

And test whether your email address has gone stale

And what do "we" do if it has? I'd want that agreed and implemented before anyone thought to start emailing an annual anything.

[dagolden]

To Gabor's original question, I don't object to telling people to list "type" as "private" if they really want to say "Yes, I use a repo, but no, it's not for you". The spec says type "should be the name of the most common program used to work with the repository" but it's not actually restricted only to enumerated types.

I'm not sure if that should be added to the spec document itself (to establish a convention), as I don't know that encouraging people to list 'private' is all that helpful, but I wouldn't really fight a consensus that felt it should be so documented. It's not a spec change so I think it would be permissible.

[neilb]

And test whether your email address has gone stale And what do "we" do if it has?

Shooting from the hip:

• send these email addresses to a (list of) volunteer(s), who can try and ferret our up-to-date contact details. If the person replies with "me no interested in CPAN no more", then their dists can be flagged with ADOPTME. Who the f**k would volunteer to do such a job? Well me, for one. And I know someone who's good at searching people out ...
• flag the user somewhere (eg a column in the users table in PAUSE), so that PAUSE admins can see that an author is 'currently uncontactable', should someone apply to take over the one of his/her dists. And if the email address were subsequently updated for the user, then the flag would be cleared.

Ie we don't actually "do" anything, we just record the fact. I could use it to give it a +1 on the adoption list, for example.

[karenetheridge]

unwarnocking: sounds like we could take a PR that amended the 'repository' documentation to state that any stringy value for 'type' would be acceptable, and explicitly listing some popular choices: 'git', 'svn', 'mercurial', 'private' (which now makes me wonder if we have any preference for 'svn' vs 'subversion', or 'mercurial' vs 'hg' -- @szabgab, do you have stats that can answer which is used more?)

[rjbs]

• Karen Etheridge notifications@github.com [2013-10-01T15:43:54]

  unwarnocking: sounds like we could take a PR that amended the 'repository' documentation to state that any stringy value for 'type' would be acceptable, giving some popular choices: 'git', 'svn', 'mercurial', 'private' (which now makes me wonder if we have any standard for 'svn' vs 'subversion', or 'mercurial' vs 'hg' -- @szabgab, do you have stats that can answer that question?)

The spec already establishes the standard here: use the string of the command you would run. svn, not subversion. hg, not mercurial.

rjbs

[book]

The CPAN Testers are already managing a list of authors not interested in getting the daily CPAN Testers summary at https://prefs.cpantesters.org/. So there is some experience here to draw from.

I very much like the idea of a yearly CPAN reminder, that would point at all the existing collection of services (and point out the new and shiny ones), and maybe even summarize the results for things like conforming Changes files, CPANTS score, CPAN reviews, etc. It should be possible to opt-out, althought it's probably less important than for the daily emails sent by the CPAN testers.

[karenetheridge]

It's only daily if you have failing modules :)

(speaking of which, I'm in withdrawal now that we're into the 5th day of cpantesters upgrades... starting to get the shakes...) ;)

[dagolden]

Daily! I remember back when every FAIL report arrived as a separate CC'd email!

[ribasushi]

@karenetheridge It's only daily if you have failing modules :)

Failing by whose standards...? CPAN is not all one might think it is - consider https://github.com/CPAN-API/metacpan-web/issues/128#issuecomment-24305393

[karenetheridge]

Failing by whose standards...?

@ribasushi: The context was cpantesters daily report emails -- therefore I meant "failing" as in when ./Build test or make test fails on a cpantesters box. I wasn't expressing any opinion as to the validity of those tests or whether the failure is genuine (or even what a "genuine" failure even means).