Issues Log

[Vangelis forthnet]

On Mon Apr 17 23:05:51 BST 2017, tellyaddict wrote:

> Is it just me or has the GiP Issues Log disappeared from github?

If you are referring to the GitHub repo issues tracker
formerly available at

https://github.com/get-iplayer/get_iplayer/issues

then no, it isn't just you... :-(

 In an unannounced, unforeseen, unprecedented, unjustifiable
and, frankly, alienating move, the issues tracker has been
purposely obliterated from the repo by its maintainer a little more
than 24 hours ago...

 This fact has caused me serious grief/distress Monday afternoon
and I decided not to post to this list at the time, not being
confident I could control the "political correctness" of my language,
due to anger and frustration...

I, for one, found the issues tracker to have been a veritable vault
of invaluable info/documentation on the way GiP evolved/changed
over the last years and a very easy reference to the actual commits
that brought on those changes.

 The way the tracker worked was that usually the maintainer would open
a new issue for a new feature to be implemented or for a new bug to be
fixed and if/when that issue was closed by a specific commit,
that commit would have been mentioned there and easily linking to
the actual piece of perl code that would implement changes/fixes.

The provenance of reported bugs would be at first this list, then the
Support forums and the issue tracker itself; yes, the tracker was the
only alternate avenue a user (with a Github account) could contact
the coder directly (if said user wouldn't create a forum account, for
whatever personal/practical reasons...).

Truth be told, the tracker wasn't the most hospitable of places for the
casual github member trying to report a GiP issue experienced, what
with the very strict issue template and various others restictions imposed
(most often an issue opened by "a third party" was hastily locked
and the person directed to the forum for support).

I personally posted 4 or 5 times there with what were genuine bugs,
not feature requests, but alas I am not a perl coder, so I couldn't fix
myself those bugs by submitting PRs :-( (I was instructed to do that on
my latest issue opened there, pertaining to an artificial geo-block GiP
imposed on some globally available clips...).

I am following quite a number of Open Source software on GitHub
and elsewhere (bitbucket), 99% of those do have issues trackers and
really value the input on those from not only experienced coders
but from the average Joe who has discovered a new bug...

Having the Support Forum is a nice thing, I guess (opinions may vary
here) but the issue tracker did serve its special purpose alongside the
forums. And as I said already, the documentation contained inside all
325 closed issues was of great value... I explicitly recollect a case where
I was trying to locate a specific commit that introduced a specific change
and as much as I'd searched on the commits' titles/descriptions,
I couldn't find it... It was only inside the closed issues list that I 
managed
to locate that one commit...

As an outsider, I fail to grasp the reasonning behind the tracker's removal;
if it were a maintenance burden or an attempt to control spam (of which
very little existed), then why not keep it in a read-only mode?

FWIW, before the tracker got deleted there were 325 closed issues
and one open; the content of the open one has been moved to the
wiki section:

https://github.com/get-iplayer/get_iplayer/wiki/Home/_compare/bd03977%5E...bd03977

https://github.com/get-iplayer/get_iplayer/wiki/issues/_compare/8783bd9%5E...8783bd9

Now the hard truth remains that as much as GiP is a project
with countless users, it is an "enterprise" run by only one-person
(especially when its ties were severed from infradead.org and D.W.).
That "one person" chooses to move GiP to the directions that
person sees most fit... and in the process spend personal time/
resources without charging us, the users, a single penny...
The question is are we, the GiP users community, entitled to pass judgement
on the decisions made by the sole code maintainer or not at all?
I fear the consensus is if it's Open Source, then stay content
with what is being offered, for the duration it's being offered...

Apologies if some were offended by my venting tone...

Kindest regards,
Vangelis
(a GiP enthusiast since 2010)