Kivy
Replies: 9 comments 3 replies
-
Your presence and questions are valued, and we're here to provide helpful responses, not to see you as a sinister figure. |
Beta Was this translation helpful? Give feedback.
-
|
I started with Buildozer, because it is the Kivy project I am most familiar with, and checked out a few small projects I am unfamiliar with because Kivy\Kivy is huuuge and scary, and I want to be experienced before I start. Kivy/Buildozer: Before I started there were 213 open issues. After I went through the database there were 101. A few days later this was down to 90. (I consolidated many, and prompting people to update caused a few to be closed by the OPs.) Kivy/Plyer: Before: 149. After: 103 (including 2 new ones I submitted) Kivy/Pyjnius: Before: 139. After: 74. Kivy/kivy_pong_demo: Before: 1, After: Still 1, but I submitted a PR to fix it! Kivy Discussions: Before: 6, After: 3 (But I have created a couple myself since then!) Kivy/kivy-website: Before 9, After: 6 (including 1 new one I submmited) Kivy/oscpy: Before 13. After... No change at all. Good job at keeping this database clean, maintainers. kivy/templates: Before: 0, After: 1 (What a failure at cleaning up! I submitted the first issue) kivy/kivy-ios: Before 72, After: 52 (Not knowing the technology does make it harder to judge,) |
Beta Was this translation helpful? Give feedback.
-
Today's dilemma: Dealing with bountiesBountySourceI notice a lot of old issues have some automated text inserted suggesting that the OP might like to offer a bounty via BountySource. While their front page is live, BountySource's app no longer works and the bounty links are broken. Based on their issue tracking page, they are no longer paying out bounties, and users are mad! I have no idea whether any Kivy users or developers were affected, or what issues had bounties offered. Cleanup:I confess I haven't worked out where the automatically inserted text came from. I can't find a history of it being part of the issue template, or signs it had been added by a bot. Shrug It doesn't seem to be added any more, so I don't need to change anything to stop it. It would be nice to have a bot go through and remove this text from the issues. I have neither the privileges nor skills to do this. Nor is this a priority. Informal BountiesI have come across issues where the OP informally offers a bounty to have it fixed. At least one was effectively on a support question - there was no PR required. I have decided to take the policy that an informal offer made 2+ years ago by an anonymous Internet user isn't worth the paper it is written on, and to not consider it when deciding how to deal with issues. If you think that is a bad idea let me know. Alternatives
If you are coming up with a new way Kivy can support bounties, consider rewarding not just the person submitting the code change PR, but the people who review it, offered support advice, and updated the unit tests and documents. Should we share the tips? This is not a serious proposal. Just got me thinking, that's all. |
Beta Was this translation helpful? Give feedback.
-
Unfortunately, someone got impacted, and I guess now hopes to get it back online are barely 0. |
Beta Was this translation helpful? Give feedback.
-
Better to move this discussion into a separate thread, however, based on how bountysource worked, splitting the tips was not possible. |
Beta Was this translation helpful? Give feedback.
-
|
Kivy Themes: Going through the Kivy framework defects there are various themes I am noticing:
I know nothing about these technologies. I suspect these require major rework in Kivy. I suspect there have been previous discussions about them. But these are the areas I am seeing where solving the fundamentals will close off lots of outstanding defects. |
Beta Was this translation helpful? Give feedback.
-
|
Both (1) and (2) are planned. The first step, regarding (1) will be kivy/kivy#8226. I'm still working on it, and testing different approaches. (I think I took a decision, but since it will likely require a major release, we will not see it before Kivy "next" ( After |
Beta Was this translation helpful? Give feedback.
-
|
Another theme I am noticing is plenty of older issues where the OP has found the cause of the problem and provided a solution. Often, they just post the code change in the text of the issue - and it is just sitting there ready to be plucked. Sometimes, they commit the change into their own fork, but don't submit a PR. Sometimes, the submit a PR and lose interest when review comments come back. Sometimes, the PR never gets any attention from reviewers. I am pondering the idea of a new label: "Needs-Foster-Parent" I see this as one step above the "Easy" label. The hard work of debugging, finding the cause, and figuring a solution has been done. What is left is mainly paperwork. Should get good value for the effort of a junior programmer, and help build them up for tackling larger issues. I wonder if such tasks will appeal to people who want to have real impact on Kivy problems, but in digestible parcels. |
Beta Was this translation helpful? Give feedback.
-
|
Let's talk about GitHub Labels. BackgroundMost issue-tracking databases either:
GitHub offers only the very basic workflow - an issue is open, closed as completed, or closed as not planned. The rest is left to a project to implement through labels. Labels have a name, description and colour, and can be assigned to issues and PRs. The creation and editing of labels requires more core dev powers. The assignment can be done by core devs and also the Triage Team (currently: me). Automated bots can be used to act on labels. Examples include closing support tickets with a standard message, or closing tickets where the original poster doesn't respond to requests for more debugging information. Why use labels?Labels are useful for when you want to search or filter for issues that satisfy a particular criteria. Maintaining labels is an admin overhead. We should only do so if there is value in it - we have use-cases where a label makes it easier. That includes: the progress of the issue ("I am a code reviewer; what can I review?"), the areas of expertise required ("I am a Raspberry Pi expert; what bugs need investigating?"), and various project planning aspects. If there is no use-case, we should not maintain the label. Labels and Kivy projectsI surveyed 26 Kivy repositories that were not archived and not forks, including kivy/kivy, kivy/python-for-android, etc. The number of labels defined per repository ranged from 6-48, with a median and mode of 8. There were many tags had the same role between projects, but differed unnecessarily; there is an opportunity to standardise, and I may make some proposals about that. Grouping together equivalent ones, I counted 78 different label definitions. There were many tags that appear to have no value. In my opinion, about a third could be removed/deprecated. An Aside on Bug TrackingMy experience with sofware developers and issue-tracking is that:
For that reason, I normally demand strong justifications for any states, labels, etc. in an issue-tracking database to try to dampen down this cycle. Kinds of Label[This is an opinionated classification - GitHub dosn't make the distinction. Some projects use label colours to make distinctions between them.] Progress LabelsThese document the issue's current state. Examples include Status: Confirmed, need-discussion, pending-downstream, help wanted I will propose deprecating a number of the state labels. Close ReasonsThese document the reason why an issue will not be worked on. Example found include: duplicate, wontfix, invalid, spam, licensing, support Most of these are defaults suggested by GitHub. We do not tolerate support requests in the issue database, so the label I do not think the rest are ever useful. All of them require a comment on the issue explaining to the originator why they have been classified as such, so anyone looking at the issue can tell why. I cannot think of a reason to "Search for all issues marked as a duplicate" or "Count the number of invalid issues." I will propose deprecating all of these, except TypeThese include: support, question, bug, documentation, enhancement, testing-pull-requests, KEP, Type: Regression, Type: Feature, feature-request All "Question" issues will be closed as "Bug" is useful as a label acknowledging that the issue has been investigated, and we acknowledge this is an actual defect in Kivy code, not a bug in the user's code or a misunderstanding. "enhancement", "feature" and "feature-request" should be consolidated into one name. I don't feel strongly which, but "enhancement" has the benefit of including refactoring requests; the others sound like they wouldn't. "Type: Documentation" and "Type: Regression" aren't useful, and I shall propose deprecating them. (Note: The same project has a "Component: Documentation" that is.) "KEP" seems to have been an experiment; it seems to be synonymous with "enhancement". ComponentThese describe which part of the project's code will (likely) need to be edited. This is useful to experts to identify where they can be most helpful. These are naturally different between projects. A few of the projects have "python3", "py3", "Python3" etc. labels. I will propose to deprecate those. PlatformPlatform is similar to component in helping experts identify where they might be useful. Example of platform labels include: Platform: Android, Platform: Browser, SDL2, PyGame, ndk-r19+, platform-conda, distribution-docker, suggest-android_new Severity, Effort and PriorityThese are three related concepts that often get confused in issue-tracking. SeveritySeverity describes the impact of the issue on the users - the more people who are affected and the more seriously they are affected, the higher the severity. A spelling error in a document in a technical document would be low severity. Crashing bugs, data corruption or performance issues that affected a large fraction of users would be high severity. Examples of severity labels include: important, RELEASE BLOCKER and security. We don't have severity labels for low severity issues. EffortEffort describes how much work is involved in addressing the issue. Examples of effort labels include: easy, good first issue PriorityPriority describes which issues should ideally be solved first. Examples of priority labels include: Priority: Low, Priority: Medium, Priority: Critical, Priority: High, bounty, Hacktoberfest Priority is roughly proportional to Severity divided by Effort, but there may be other scheduling factors. [Note: This means, for example, fixing a spelling error doesn't need to wait until every other issue is solved first.] Bounty and Hacktoberfest should be deprecated. Fix ImpactThese labels highlight the impact of changes for future release documentation: Examples include: FAQ, Notes: API-break, Notes: API-deprecation, Notes: Release-highlight The FAQ tag is a concern because it requires action to be taken when there is no open issue to track that, so it will likely be lost. This needs futher consideration. |
Beta Was this translation helpful? Give feedback.
-
|
kivy/kivy: Okay, I am calling it. I have attempted to look at every open issue. I may have missed a few, but hit over 99%. What were the stats? Before 920, after 680. That doesn't mean I personally closed 240 though. Because it took me a couple of weeks to get through the list, other people have closed some (including those who were prompted by me), so I don't get credit for that. Also, some new ones were created in the meantime, so it may have been a few more. There are also 35 sitting with an "awaiting-reply" label. A bot will close those in 6 weeks (I increased it from 2 weeks) if they haven't got an answer. I estimate that will close another 25 more. |
Beta Was this translation helpful? Give feedback.
-
|
Question: Historically, on the Kivy Framework project, if I raised an issue, how long before it was closed? [Note: I am talking about when the issue is closed, not when it is fixed, which might be never (if it was closed as Not Planned), might be later (if it was closed as a duplicate) or might be earlier (if it was independently fixed and the issue remained open).] Answer: 19% get closed within a day. 50% get closed within 11 days. 16% are still open after a year. [I posted this on Discord and included some graphs showing percentages over time.] |
Beta Was this translation helpful? Give feedback.
-
|
kivy/python-for-android: There were 268 open issues, and then I raised 3, bringing it to 271. After that, I reviewed them all, and there are now 180. |
Beta Was this translation helpful? Give feedback.
-
Hi,
My name is Julian. I was recently appointed to the freshly-created Triage Team. That give me the ability to close issues and assign labels to issues (and not much else).
My priority is to go through all the issues, and clean them up. It is largely an admin task, and I figure every hour I spend on it is another hour that the core developers can spend on reviewing code, writing code, and setting project directions.
The most obvious clean up is closing down support requests - i.e. if the question is about finding bugs in the user's code, rather than finding bugs in Kivy's code, it doesn't belong here.
Other clean ups include: closing issues where the bug has been fixed but the issue is still open, closing issues where the original author has not responded to requests for more information and finding duplicates.
Note: While I am striving to be diligent, the topics can be complex to understand and comments are not always clear, so I may make some mistakes. If you see an issue closed when it shouldn't be, please let us know so it can be corrected as soon as possible.
This discussion group is to communicate my progress and to invite questions: I don't want to be seen as a sinister shadowy figure in the background, mercilessly striking down your precious questions without any accountability or recourse.
Beta Was this translation helpful? Give feedback.
All reactions