First steps towards contribution recognition

You’re conflating two different things (which is why the “quotes” were needed to stretch the definition and make your point.) I’m talking about how it’s going to look to the public (appearance). I don’t care if my name is on the list or not (credit), I just don’t want it to look bad.

Reading through this thread, this was what I was going to suggest, but also, do we have a page for each release? Or is that something only at GitHub? Each release should at least list the code contributors.

1 Like

I’m sure some code with GitHub api can do that with some additional code, I didn’t check thou.

We probably should not have single pages for each release but maybe a blog post with a shortcode could be done for each single release?
(could)

The link inside the cms technically exists already so as for main contributors page that would be just waiting for the visually appealing list of contributors

page/post whatever… Like WP publishes a release post for each, which summarizes the contents and has a list of contributors.
release category
5.8.1 release

Nice design!

Aren’t we routinely connecting to https://www.classicpress.net/feed/ for news and https://api-v1.classicpress.net/features/1.0/ for petitions?

1 Like

I’m hoping we can keep publishing blog posts for each release, which I started with 1.3.0.

2 Likes

<sigh> Yes, unfortunately the dashboard page connects to those. I always unset those widgets in the wp_dashboard_setup hook because ClassicPress’s server logs should not know when my clients are logging in.

1 Like

Me too, but it’s more for de-cluttering reasons.

Technically they don’t. Requests are anonymized, domain is hashed using sha1(). So CP can tell unique websites apart for reporting but it doesn’t know which websites are making those requests. There’s more info on this in the usage report.

Apache server logs contain the HTTP Referrer - the URL making the request, including querystring. So that info will be in the logs for www.classicpress.net and api-v1.classicpress.net unless this has been disabled in the browser or code making the request.

The Referer header (typo preserved for historical reasons) is only sent by browsers, or by other user agents that specifically and purposefully include it. These requests are made by the ClassicPress PHP code, and ClassicPress does not send this header.

This is correct.

1 Like

Very good to know.

For sure (but not tested) you can get commits between tags and then get info about authors.
This need to use an API key (60 query/hour is not enought to get results).

I like the idea of better about/credits page in wp-admin but it should be created when builds are made for release … Using a script or something so there is only ever one ping to the GH api.

3 Likes

Of course! I can’t see any reason for this page to require constant pinged updates. Can’t it just be updated prior to a release and then hard-coded in?

I also don’t like the numbers as it makes it look more like a ranking. I would just have names and maybe avatars/images.

2 Likes

sounds good :slight_smile:

An update of some progress here…

I have a new version of this “script” that allows to do all of this without a single ping to Github online instance (thanks @james for the hint to use git log)

It requires a single command to be run on a server with a clone of GitHub Develop Branch of CP.
This command needs to be run regularly (perhaps thru cron), and it creates a log of committers and their name/email:
git log --pretty=format:"%ae%n%an" --since="2018-11-01T" | uniq > log.txt

Then, a tiny code can be used to:

  • create an array from the logged data
  • cleanup the that array from unwanted duplicates
  • cleanup the that array from unwanted bots
  • do whatever sort of fancy output that pleases all eyes with it, and do (or do not) link to respective urls based on commit author name, email or whatever else we want.

The PHP for that is relatively simple too:

$file = file('/path/to/log.txt', FILE_SKIP_EMPTY_LINES|FILE_IGNORE_NEW_LINES);
$log_chunks = array_chunk( $file, 2 );
$array = array_combine( array_column( $log_chunks, 0 ), array_column( $log_chunks, 1 ) );
$simplify = array_unique( $array );
$cleanup = array_diff( $simplify, array( 'renovate[bot]', 'ClassicPress Releases' ) );
//do whatever you want with $cleanup at this point, it is an array of '[email protected]' => 'User Name', without duplicates and without unwanted bots, and without matt.

The “old” committers are excluded as per date set in the command to create the log.
It is completely without any ping to remote, and could be used to basically create all sorts of output we want (on our contributor page, not on each single CP install, of course).

Also with this system, if anyone is not happy to be listed, they can be removed relatively easy.

It would even be possible to use this for a remote API if we want, we would need to put the “log” into a proper api response, and make it available on some remote URL.

Does someone know the exact date when CP was forked out? That would be required to set the precise starting date so to not get unwanted commits but also not lose any.

Using git log is the correct approach, but this is going to need some refinement as we don’t want to pull in authors of WP commits. We need to be excluding these contributors by default instead of “if anyone is not happy to be listed”, because we already know these contributors are not happy to be listed.

It may be easier to set up parsing as a simple text file, but there will be other kinds of manipulation needed before the data is usable. Code that has access to more properties of each commit is going to end up being the best way to do this. I have successfully used GitHub - nylen/php-git-log-parser: A parser, written in PHP, for logs generated by git log for this purpose (ugly but working example code here).

The last WP commit has the tag LAST_WP_COMMIT in our repo: Customize: Increase the colour contrast of the line numbers in CodeMi… · ClassicPress/ClassicPress@d7b6719 · GitHub

1 Like

These authors are excluded, since it is by date (since), according my tests this works fine, no WP committer was showing up in the generated log. It seems to me that the log command takes commits to CP (well, at least, I could confirm that all CP committers were listed, but none of the WP folks - so that should be good)

With exclusion I did mean if anyone contributing to CP would like to be excluded (you never know), we could do that relatively easy.

I have tried said library, but I stumbled on issues of undefined class Command (I used the examples you provided me in PM of slack)
Surely I did something wrong, since we seem to use that library successfully, but … well, neither me nor the code seem to be able of finding said Command class, the library doesn’t include it.

This why I took the “simpler” approach of storing the log in a .txt file (the log is minimal but could include or exclude any piece of information we would like and is supported by git log)
Since that command can be run with a CRON, it wouldn’t need any manual interaction, and we can read off that file putting it into the PHP variables to create some minimal output (after all folks did not want avatars and the like, so I think a name is enough? As far I am concerned I would do something like current WP Contributors page (inside the CMS) has: avatar and link + name. But… if folks don’t want it, I am not insisting)

I’ll be in touch in PM to eventually try the library again, although, isn’t it overkill if we can do it with a single command line + a PHP (minimal) output?