MartijnKaijser
commented
5 years ago First of all github is for issues (not requests) and second i rather remove the stupid install from URL completely
Closed kekukui closed 5 years ago
MartijnKaijser
commented
5 years ago First of all github is for issues (not requests) and second i rather remove the stupid install from URL completely
kekukui
commented
5 years ago github is for issues (not requests)
The issue here is both a design defect and a semantics error in the user interface (which combined together have wasted countless man hours.) And if requests are not welcome then why are requests enabled on this Github account? If you dont like it, you should just disable suggestions and then explain where such proposals should be directed.
i rather remove the stupid install from URL completely
I'm sure developers of new legitimate add-ons (and their beta testers) would really like that :roll_eyes:
MartijnKaijser
commented
5 years ago You didn't see the "Team Kodi members only" note
kekukui
commented
5 years ago You didn't see the "Team Kodi members only" note
And you didnt see the defect which makes it a real issue, because you are blinded by rage towards the pirates. But I am not a pirate, and my proposal addresses a dysfunction in an existing feature. It is therefore a process bug and thus a legitimate issue. I think the entire team should vote on whether you handled this item correctly and discuss how process bugs should be handled in future.
yol
commented
5 years ago @kekukui Answering to legitimate explanations about our process with accusations is not going to help you. You tried to make an argument that we do have feature requests on GitHub by deliberately ignoring the "members only" part, and when pointed out you ignore that argument again and just go rambling on about something completely different. With that attitude, I guarantee you that it will be difficult for any team member to find the motivation to consider your wishes.
It is therefore a process bug and thus a legitimate issue.
There is a thin line between a feature request and an issue. With enough jumbling around, you can make anything into the other. You can say "I request feature X" or you can say "it is a bug that feature X is not there". In this case, this behavior has been there for years, and we are disinclined to see it as a technical bug, which is what we use GitHub for currently.
Using GitHub issues is kind of new for us, so we haven't completely finished discussion on what we want to accept here and what not. Process bugs rarely come up and are difficult to locate on the request/bug spectrum, so we are still discussing this. It is unlikely that we will consider process bugs on GH that do not screw up your user experience in a major way, which is not the case here.
That said, reading the "problem report" template (which you chose to ignore and remove), it should have been immediately obvious that your report does not fit. You are therefore requested to open a thread in the feature requests section in the forums.
yol
commented
5 years ago Side-note: It was never intended to work this way. That you can install from URLs using the "Install from zip" option is a completely unintentional side-effect of the way Kodi's file management works. If we could easily disable that without compromising other functionality, we would have done that long ago so there would not be this confusion.
kekukui
commented
5 years ago @pkerling
I did not want this issue to be about Martijn, but if you are going to make it about me (instead of improving dysfunctional policy and procedure), then I think turnabout is fair play:
Answering to legitimate explanations about our process...
Martijn essentially contradicted a published statement about the process -- he did NOT attempt to explain the process and did NOT attempt to direct my report to the forum. He even admitted that he wants to remove this functionality completely, instead of reducing its complexity. That was in no way a "legitimate explanation".
...with accusations...
This seems really hypocritical to me: By insinuation, Martijn basically accused everyone who uses this feature of using it for an illegitimate purpose. His opinions on this subject are well known in the Kodi community and his reply should be understood in that context. His application of the word "stupid" is proof of his intent. He made the first accusation, but you will not acknowledge it because it was not literal, it was interpreted.
...is not going to help you.
I really dont expect help. I am only expressing a design philosophy (that Kodi should be more user friendly) ...but some people clearly do not agree.
You tried to make an argument that we do have feature requests on GitHub by deliberately ignoring the "members only" part
I was merely pointing out that his statement technically contradicts the official statement. He was the one who mentioned the subject first, and I responded. I believe he employed this as a diversion because he actually closed the issue for personal reasons, not professional reasons. This claim is also based on his past performance (because he often tries to censor discussion in the forums too.) So I have to disagree when you claim there is a venue for these discussions. It is nowhere near that simple.
With that attitude, I guarantee you that it will be difficult for any team member to find the motivation to consider your wishes.
I dont know if you speak for the entire team, but I will treat your response as such in the absence of other replies. However, I do want to clarify here that the bug report was not for me alone, it was an attempt to bestow a modicum of common sense on a poorly designed user interface which affects countless others.
There is a thin line between a feature request and an issue.
Not in this case. Video game support (which you actually did) is an example of a feature request. A process bug is where an existing feature was implemented incorrectly. I think you are being disingenuous here for the sake of winning the debate.
With enough jumbling around, you can make anything into the other.
And that is precisely what you are trying to do here, in my opinion.
You can say "I request feature X" or you can say "it is a bug that feature X is not there".
Your illustration is not valid because the capacity to install repos from the internet actually is there already. But the user interface is dysfunctional. The solution is to streamline the process by adding a menu option which is really a SHORTCUT to an existing routine. This can hardly be construed as a new feature when the functionality has already been coded and you are simply changing the way it is invoked or presented to the user.
In this case, this behavior has been there for years
So you think bugs should not be fixed if several years have passed without a solution being proposed? And you are calling me stupid?! In cases where the skin has a user interface bug, my GitHub issues have been accepted. I have also contributed to the UI design of many other apps. So the vicious reaction to this bugreport honestly came as a surprise to me.
and we are disinclined to see it as a technical bug, which is what we use GitHub for currently.
Process bugs are technically bugs. But rest assured that I will not submit another, after encountering reactions like this.
It is unlikely that we will consider process bugs on GH that do not screw up your user experience in a major way, which is not the case here.
I know many people who think this is the #1 annoyance on the Kodi platform. And the only feature which is used more than INSTALL is UPDATE. I challenge you to find one experienced Kodi user who is not affected by this design flaw. Now consider all of the time that every user has spent installing add-ons from external repos in this cumbersome fashion. That is a major "screw-up" indeed -- particularly in terms of usability and productivity:
There are countless web pages which attempt to walk the new user through the process of installing add-ons that do not reside in the official repo. That is a lot of time wasted too (some of which could have been spent on development and documentation.) While some of those add-ons are probably banned, there are still many non-infringing add-ons in this category* (and some of those sites invite the user to propose new ones.) Legitimate Kodi users should not have to suffer with a crappy U.I. just because you dont like the jerks who make those grey market builds!
_* A notable example is Security Shield, which performs the following functions:
**1. Clean old add-on data
Again this speaks to the user interface: all of this functionality should exist natively in Kodi. You guys basically argue that Kodi's application management should not be improved and external repos should not be supported -- but what is the point of open source if you dont have freedom of choice? If you want a closed platform which treats the user as property, why are you working on Kodi? Go buy a Roku or Apple TV !
Some other examples of non-infringing apps which are not in the official repo include: GA Checker (which reveals hidden code and the undisclosed use of Google Analytics), malware scanners, internet speed tests, CPU or disk performance tests, and P2P broadcasting apps (which are used by various schools, churches, universities, political parties and municipal governments.) Many legitimate add-ons have not found their way into the official repo, and submissions are not always approved in a timely manner. It is unreasonable and impractical to restrict a computing device to a single repo.
That said, reading the "problem report" template (which you chose to ignore and remove), it should have been immediately obvious that your report does not fit.
And yet, the language in the Issues section seems to welcome submission of things which "dont fit." I think you have to admit that is a little confusing. Now, if you are rejecting my report on that basis, I will accept the decision, of course. But I believed the issue was so simple and obvious that the template was superfluous. I also believe this design flaw is so fundamental (and wastes so much time in the aggregate) that it deserved recognition here as an exceptional issue. I know that rules and procedures have a purpose, but sometimes a minor exception is what stimulates progress. In this case, it actually takes more energy to discuss the issue than it does to fix the problem. I would also point out that the template was not cited as the basis for marking this bug report invalid: the disqualifier here was that Martijn thinks the feature is "stupid" and should be deleted, not fixed. (But how can this bug report be a "feature request" if both of you admit the feature already exists and you wish you could kill it?)
You are therefore requested to open a thread in the feature requests section in the forums.
Understood. (But not sure if I will bother at this point.) Sometimes it's really confusing and frustrating: on the one hand I see people like Professor Yaffle calling for new developers, designers, and everyone with a vision of how to expand the user base by making Kodi more user friendly. And then we have other team members who seem to want the opposite: they want to crush the dreamers vision, and put the brakes on audience growth and U.I. improvement. (And some have explicitly acknowledged that too.)
I believe the evidence shows that public relations is essential to a platform's success, particularly where open source is concerned. But there are a few people on Team Kodi who have given the group a reputation for being unnecessarily difficult... and even some developers have conceded as much. I am spending a lot of time to discuss this today, but I really am tired of debating. If the dysfunctional installer will never be fixed, I will start using and promoting unofficial Kodi builds or Android alternatives (which is something I hate and never thought I would consider until now.) And I'm sure you will say "good riddance." At this point I only want to know what percentage of Team Kodi agrees with you and Martijn on this design issue.
That you can install from URLs using the "Install from zip" option is a completely unintentional side-effect of the way Kodi's file management works. If we could easily disable that without compromising other functionality, we would have done that long ago.
I believe you are referring to the fact that we can install things from an external repo by creating an alias in File Manager. Now you say you cannot disable internet access in File Manager because it serves another purpose. (Like what, browsing for pirated movies on some file hosting site?) This is not a credible argument either:
If you wanted to link the "install from zip" menu option to a clone of the File Manager which has no internet access, it could easily be accomplished. I really do not hate you guys, but I cannot take these arguments seriously. That said, I am not attempting to undermine your policies and procedures. I am only addressing bugs in those policies and procedures. If you want me to fix this, I will happily write the "code" for you:
"New issues created for this project on GitHub must address features which fail to work reliably or fail to work as described in the documentation. No bug reports will be accepted in this venue which attempt to address flaws in the user interface design or features that were implemented in an absurd, obtuse, incompetent, ugly or nonsensical fashion. Any flaws which do not qualify as GitHub issues should be addressed in the forum at [insert correct URL here]."
This notice should appear in the place where it currently says:
yol
commented
5 years ago You again resort to personal attacks and claims/insinuations that are factually false (most obvious point: "And you are calling me stupid?!" - No, as you can read for yourself here no one - and certainly not I - did so). I do not have anything to add to what I already said and do not feel further discussion will get us anywhere.
Thanks for your input, we will try to take your feedback about how we design the template and issue submission process into account when going over how we want to use GitHub issues in the future.
In Settings / Add-ons / Add-on browser there are 5 menu options:
**1. My add-ons
PROPOSAL: If Settings / System / Add-ons / Unknown sources = ENABLED, display an additional menu option:
---> "Install from URL"
REASON: If you want to install a new add-on from an unofficial repo, you must first add the source to File Manager. After several months you may have polluted File Manager with aliases for network paths that were only used once to install a repo. There is usually no need to retain an alias for the network path in File Manager after the repo has been installed ; it just creates unnecessary manual cleanup work for the user. Instead of creating and deleting sources in File Manager, it would be preferable to type the network path once while installing a repo and then forget it. This menu option would perform that function.
For improved technical accuracy, "Install from zip file" should also be renamed "Install from File Manager". (It is irrelevant that installers are zip files: the most important goal for this menu is to clearly express the difference between the available installation methods.)