Replies: 4 comments 3 replies
-
|
For me the biggest issue right now for this project is the people asking for new feature in releases discussion. People interact altogether and ideas but also noise are happening there. |
Beta Was this translation helpful? Give feedback.
-
Yes, this is an intelligent way to manage a project — a rather comprehensive roadmap + "issues" in one. That allows for developers to see what feature set they may want to work on and to minimize pull requests — complete the entire feature set, bug check, etc, without constantly requiring the maintainer's time & energy. And the issues integrated would help everyone as well. Users and developers can see in one place where the project is headed, what to work on, what needs fixing, etc. Often duplicate issues are filed because the search function sucks — if you don't guess the exact wording someone else used then you won't find the issue. 🤷♂️ However this is all up to the maintainer, they get to choose how to run the project — do they want to constantly answer user's questions, point users back to documentation, etc or appoint someone to maintain such a document & oversee "managing" issues and features so they can focus on coding? I spent about 5 years working with a developer on an open source CMS — I used my time for research, bug checking, maintaining documentation, and dealing with the forum, some minor coding — passing on questions when I didn't have the answer — to help the developer focus his time on the necessary things that he was most needed on. IMO that's how a good open source project works — developers + advanced users to maintain the project. But what do I know 🤷♂️ just another nutter 😂 on the web |
Beta Was this translation helpful? Give feedback.
-
|
I was thinking the same from developer's perspective. Suppose developer will implement new feature / bugfix, but later find out there are other related issues / requests which affects an already implemented code in such way, it has to be all reconsidered with new ideas and completely refactored. If issues / requests were kept well-organized, all related aspects could be taken into account in advance and will help to avoid later refactoring (refactoring = the earlier effort is thrown all away and possibly indroduces new bugs). |
Beta Was this translation helpful? Give feedback.
-
|
Yes, it's having a clear and comprehensive roadmap as possible but this requires advanced research into areas. Since soft keyboard are a rather known quantity and there are many others to utilized for research — what works vs what doesn't etc. — it's not impossible to make a rather comprehensive roadmap with alternative feature sets (eg toolbar vs edit layout). Buuuuuuuuuuuuttttttttttt....... That requires research, lots of time researching. And it's been my experience developers don't do that all that much 🤷♂️ and are often unwilling to listen to users that do the research 🤷♂️ |
Beta Was this translation helpful? Give feedback.
-
If users decide to not use the search function despite being asked to (in the issue templates), there is not much I can do.
Links between issues can be added by any user (just reference the other issue with
I don't think this would be much help against duplicates. My impression is that many users who create duplicates don't even bother reading the 15 word tl;dr section of the issue templates, so I doubt summarizing anything in more words would help. But creating and maintaining this "issue tree" would require a significant amount of time... (and in the past few months I lost the overview almost completely) |
Beta Was this translation helpful? Give feedback.
-
If there is some map of issues (or something else to manage them), it can be quickly resolved by marking as duplicate and closing the issue.
Most of the users are just like that, it needs to be accepted as is :)
I'm not familiar with GitHub, but If it would be possible to configure some bot, it can be helpful – bot can go through all opened and closed issues and if any matches are found, it can put references in comment – this can be helpful to you and contributors.
Although I did that when I was going through an opened issues, and I believe there are also other users who care and do that, most of the users will not.
While this is true, that users will continue to create duplicates regardless of system being used to prevent this, it will primarily help you and contributors to resolve issue more quickly either as duplicate or leaving it open as a legit request, and also when implementing features to take into consideration all related things.
Search function is limited in this way. Users use different "language" when describing problems (e.g. "suggestion bar" vs "strip"). This can lead to difficulties when searching for related issues (both to user and maintainers).
"Issue tree" was only an idea to somehow begin the discussion with, alhough I personally do not think it would be so difficult. Yes, the initial effort would be overhelming, but once the map is done for opened issues, there would be only incremental updates i.e. when new issue is opened - find matching issue in the map, if found, then close as duplicate, else update map by inserting new issue.
This is why I opened this discussion, as I believed that having 200+ issues could be hard to manage solely relying on github tools, and the more users will use HeliBoard, the more issues will emerge :). There are also other ways how manage issues, for example, marking each issue with multiple tags / labels so you can quickly find all things you need. Users can describe issue however they want, then project maintainer will come and mark issue with all related tags e.g. #toolbar #toolbar/optional #toolbar/hide and if it affects other features then additional tag will be included e.g. #suggestion-bar. This way you can search all related issues, but it will require you (or contributor with deep app insight) to go through all opened issues and tag them. Once this is done, there would be only icremental changes i.e. adding tags on new issue or adding tag(s) if new comment is made which mentions something important. I think the most easy would be to have an AI chatbot integrated in repository, which understands context and will output all things you are looking for. Maybe it will be possible in near future :) Take this only as some ideas from random dude, as it is only up to you how to manage issues. You can even say that current state is not optimal, but it is still "doable" / acceptable the way it is now, which I respect. |
Beta Was this translation helpful? Give feedback.
-
Possibly it could be, especially if it works well. So far I perceived bots on GitHub as mostly annoying though.
This is what I do, and it helps quite a bit with managing bugs. Not so much with feature requests (_enhancement_s) though.
Current state is far from optimal. I knew I would have little time starting with February / March, which is why I pushed to have the first "proper" release around that time. But the combination of little time and much higher user activity than anticipated is something I'll need to learn to handle properly. |
Beta Was this translation helpful? Give feedback.
-
First of all, thanks to everyone who participates on this project 👏.
Short context why I landed here
Few days ago, I have discovered this amazing project 🚀 I'm really grateful for 🙏. I was a long-time user of OpenBoard – it had all features I was looking for in keyboard (open-source, privacy focused, intuitive UI, clipboard). Later, I started on using an Obsidian app (markdown notes), which pointed me to another app Termux (to write scripts for version controlled backups for my notes with rclone + git). Both Obsidian and Termux have toolbars for easier editing of the text files (notes) / scripts. Then, when I was writting something in other apps, I was really missing toolbar features of these apps, like move cursor left / right, up / down, move cursor to start / end of line, page up, page down etc. That's why I started to looking for a keyboard with toolbar and fortunatelly, found this project 🎉.
Topic of the discussion
Problem with duplicated issues
I want to discuss an options how to handle duplicated issues. Yesterday I was going through an opened issues to support good ideas and to make an idea about current state of the project. I have noticed that many issues are repeated or closely related, but are not linked together (added links to similar issues I have spotted).
The cause of the problem
I think users would not go through all the issues before reporting bug or opening a new feature request, even though they should, but I understand that if there are 200+ issues being opened, they simply jump into a new issue.
Proposed solution
I'm not familiar with GitHub's issues tracking, but If I recall correctly, there is no "whisper list" of similar issues when new one is being created (like stackoverflow do, to avoid creating of duplicates).
What can help is to create something like an "issue tree", where issues links would be categorized by topic, so if user has problem with rendering, he will quickly find rendering issues to check whether the problem is already being reported.
Link to the "issues tree" can be then incorporated into a bug / 'feature request' template or alternatively can be pinned above the issues like Plans for the next version.
This can be helpful not only to users but also to maintainers of this project to track all related issues.
Beta Was this translation helpful? Give feedback.
All reactions