minbrowser
Looking for volunteers
The volume of issues on this repository has grown large enough that I no longer have time to respond to them all, or to investigate all the issues that are being reported. If you're interested in helping out, let me know and I'll add you to the organization.
@KagamineP Great, thank you! I've sent an invitation. Let me know if you have any questions or want to talk about it.
If anyone else is interested, please let me know!
I'd love to but I'm a painfully slow coder and I am working on developing an open-source web app right now (https://www.heatflask.com). I am willing to tackle a bug or two in Min, especially with regards to my app working on it.
@antfu Great, thank you! I've added you to the organization so you can edit issues if you want. If you have any questions, let me know.
@PalmerAL Just to make sure the issue managing philosophy aligns with your preference before I work on.
Issues Closing
To me, I believe managing a small number of issues will help the overall maintenance efficient and make new issues being better handled. I would advocate closing issues as much as we could. Is that good for you?
Duplicated
Redirect to existing/older one and close the new one.
Feature Requests
After quick browsing, I found a lot of fundamental features requests like supporting favicons in tabs. The initial ones might be raised years ago. For those you commented saying not going to support, would you like me to keep the discussion or just close them and labeled with won't fix?
Please let me know what you think or if you have any additional notes. After that, I can start reading the issues and labeling them when I got some time.
Thanks :)
Yes. The issue count is overwhelming. Please close as many as possible and close any PRs that are not mergeable, and if the author feels like updating it they can reopen it.
On Mon, Jul 13, 2020, 01:42 Anthony Fu [email protected] wrote:
@PalmerAL https://github.com/PalmerAL Just to make sure the issue managing philosophy aligns with your preference before I work on. Issues Closing
To me, I believe managing a small number of issues will help the overall maintenance efficient and make new issues being better handled. I would advocate closing issues as much as we could. Is that good for you? Duplicated
Redirect to existing/older one and close the new one. Feature Requests
After quick browsing, I found a lot of fundamental features requests like supporting favicons in tabs. The initial ones might be raised years ago. For those you commented saying not going to support, would you like me to keep the discussion or just close them and labeled with won't fix?
Please let me know what you think or if you have any additional notes. After that, I can start reading the issues and labeling them when I got some time.
Thanks :)
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/minbrowser/min/issues/1080#issuecomment-657413136, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACPFEWS6LE36LQ4RZS6YMNDR3LCHHANCNFSM4ODAW5NQ .
Yeah, I agree that reducing the number of open issues would be good. Regarding the different categories:
- What you suggested for duplicates sounds fine.
- Questions - it's probably fine to close these if the question has been answered.
- Bugs - a few of these are random issues that someone had a few years ago, and that no one else has ever been able to reproduce; it's probably fine to close those. But there's also a lot of legitimate issues that have never been fixed, and that would be better to leave open. If you're not sure, I can look at it and try to figure it out.
- For feature requests that I decided not to do , closing with wontfix sounds good.
- There's a lot of issues open for low-priority feature requests that I'm probably not going to work on, but that I would be fine with adding if somebody wanted to contribute it. It's probably fine to just leave those as-is, although I guess some kind of issue prioritization system could work as well.
Thanks for working on this!
@ebrensi I agree on the PRs, I'll go ahead and do that.
@PalmerAL I am reading issues from the very beginning and sorting them out to a FAQ in #1128. I would like to label them alongside, can I have the permission to create and modify labels? My idea would be something like
- OS:
os/macos/winos/linux - Feature Request:
feat/uifeat/uxfeat/shortcutsfeat/web-standardfeat/preferenceetc - Bugs:
bugbug/uibug/securitybug/electronetc - Status:
help wantedcontribution welcomereproduction neededrequest for commentsetc
It's looking a lot better, thanks for all the work you've done so far! (and thank you Sergiy and Dmitry as well!)
I'm definitely fine with you changing the labels! I think you have permission already, and I don't see any other permission levels listed in the Github UI for that. I guess if Github won't allow you to I can just create them myself (and you definitely should be able to add them to issues).
OS: os/mac os/win os/linux
Sounds good; I think these can just be a rename of the labels that already exist.
Feature Request: feat/ui feat/ux feat/shortcuts feat/web-standard feat/preference etc
I suspect the specific categories might need to be different - for example, web standards are going to be Chromium/Electron issues that we generally can't do anything about - but the general idea is fine.
Bugs: bug bug/ui bug/security bug/electron etc
Security issues shouldn't be reported publicly, so it'd be better not to have a label for that. (Which reminds me, I need to write a document explaining how to report security issues, probably as part of a larger contributing guide. I'll make a PR with a draft soon).
Status: help wanted contribution welcome reproduction needed request for comments etc
Sounds great!
@PalmerAL So far I can close issues or labeling them, but it still seems that I can not create/rename labels.
I can't find any way to grant permission for that, so I've tried to update the labels to match what you suggested; let me know if there's any other ones you want me to create.
Hello @PalmerAL, I would like to help out. Although I don't have much JavaScript and Electron experience (I will spend some time learning them), I can atleast help out with the organisation of issues and fixing the obvious/simple ones.
HI @PalmerAL, I would like to help out as well. I've been using Min for a bit now, and I'd like to contribute to the project. Are you still looking for volunteers?
@kodumbeats Great! I think most of the work of organizing the existing issues has been done, but there's always more being filed, so you're certainly welcome to help with that :)
Let me know. I can help tackle a couple of open issues. As antfu said, there is a growing number of duplicate questions.
Hi @PalmerAL , I don't mind helping Min if you have any spare volunteer positions? I just want to contribute to the community and help Min develop faster and give something back to the community.
Are you still taking volunteers? @PalmerAL
I would like to contribute to this project, I don't have much experience contributing to open source or writing Electron/JavaScript code but I've been using Min for quite sometime now and would like to see it grow ❤️. I can start small by labelling issues or helping in any way I can..
