-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Request & Discussion] Extended rights for volunteers to help supporting your micro
project
#2956
Comments
I totally agree with @JoeKar. |
I'm sorry for the lack of communication. Unfortunately I've been focusing on other projects recently, and the time I devote to micro has been strained. It's a blessing that so many people devote time to working on micro and I regret often leaving posts without a response. I will try to respond to the recent PRs and issues this weekend and do some general maintenance. I'll probably make a new minor release with those changes next week. I think adding labels and milestones would be helpful. If you or others (generally people who have been engaged on the issue/PR tracker) would like to take that on, I'll look into how to make that happen. Thank you for your patience and your help in the development of micro. |
That sure is a stack of issues and PRs. It's nice to see you offer to try and sort it out. Micro is fantastic, I'm very thankful for it, and next time I need to pop by the repo to check some docs, I hope to see it appear as less of a burden to its creator and contributors, who so kindly share their work with us all. |
Yes, I would definitely appreciate that. With the help of labels we can tag what's really a bug and need to be fixed earlier, what's a feature request and what's a general question only. With the help of milestones the project can benefit of some sort of priority handling per next release or something like that. @dmaluka: |
Sounds good, I wouldn't mind having rights to put labels like "reviewed and can be merged" or "solved and can be closed" (as a substitute for the lack of the actual rights to merge PRs or close issues ;)). |
I am absolutely agree with it. And I want to add one small notice. If I open issues/PR's tab (especially PR's) and see there fresh activities (2 month - today) without any comments, I start to think that project was abandoned by owner. It usually scares people. If I see least see there some labels, I am not so prejudice |
Currently I've no own branch where I track my changes (used in the PRs), but usually this would be the way to go. @zyedidia: |
Yeah, just my local branch with a bunch of merge commits for the PRs I'm interested in. I was going to upload that to my fork so that others could just use it, but I've been too lazy for that. |
micro
projectmicro
project
Before we end up in more or less the same situation again after having the capabilities of labels/milestones and what ever. I've still the trust that |
It looks like now micro is a repo of @zyedidia and doesn't belong to https://github.com/micro-editor organization. Anyway what I found: repository roles for organization. I think Triage role is exactly what @JoeKar described when opened this issue. Also if Writer role is to permissive it can be restricted by branch protecting in particular via branch locking. I am not sure if I my proposal is correct from point of view what github allows but I have to propose:
|
Maybe the worst and dirty and bad solution to create separate issue where will be collected links to all the "reviewed and can be merged" PR's. But it doesn't require any super rights... |
One more PR that could be just merged #1838 (Maybe with a bit of syncing color with statusline) |
...but would fit there the best. Additionally the updated forks of It's now up to @zyedidia to carefully decide what's best for |
Or it can be ended by creating a new repo (eg. micro-next) and fix the root problem of having a single maintainer. |
From what I've read in the comments, I believe the consensus would be:
This would decentralize some functions such as The only question that remains open to me is who will do this? Will it be @zyedidia using the already existing micro-editor organization on github, will it be someone else through a fork or will we organize ourselves to do it? Do I understand correctly? |
Something needs to change so there is someone (or some group of reviewers) with authority to accept/reject changes looking at new contributions at least a few times a year. I don't think the project needs to be particularly fast-moving but it's frustrating when reasonable PRs don't get any attention for years (even if that attention would be a "no thanks" from the maintainer). I could help out with closing stale/outdated issues and adding labels such as "needs-attention" to high impact PRs/issues. |
@taconi maintains alternative plugin channel so I think he can be used for merging and maintaining original plugin repo |
Thank you, I'm honored. @dmaluka is definitely a safe bet too! So since @Andriamanitra named his self for this task I can only welcome that. The activity within the discussion section speaks for @Andriamanitra and @taconi too. @dustdfg was busy in some issues/reviews over the past couple of months as well. We should not forget the organization micro-editor, which needs some shape in the plugin section and maybe dependencies too. I already saw that @taconi is maintaining a lot more plugins over at codeberg. So he could be a predestined plugin maintainer/manager. 😄 Let us help you and by this |
Thanks, I would be happy to have maintainer's rights. It's not exactly like I usually have a plenty of free time, but there is already a number of still-not-merged PRs that I've spent quite some time reviewing (so that now I feel confident those PRs are in a good shape and merging them would make micro better), and I'm gonna continue doing so. And if someone asks me to help reviewing/approving a specific PR or to help with a specific issue, I'm happy to (try to find time to) help. |
Great, thank you very much! For now, I will give the two of you access to merge pull requests and later possibly delegate plugin maintainership as well. If possible, please send me an email so that I can also contact you for anything important that might come up. Also, please email me if you need something such as an extra review for a PR, desire to add another maintainer, request for a new release, or something else. I'll always make sure to respond to email within a few days. Thanks! |
Do you have any prediction on when the repository will be migrated to the micro-editor organization or will it not be done? |
I would ask about plugin repo if I was you |
The plugin-chanell has not been updated for two years, yes it is a point to mention, I ended up finding issues related to the behavior of the micro in the html code of the web page, the entire organization needs to be maintained and the plugins be part of this. |
I personally think that a text editor with an abandoned plugin channel is the same as an abandoned editor, because of this I will migrate to GNU/Emacs and will no longer maintain the plugin-channel or the plugins that are in micro-plugins , If anyone wants to do this maintenance for a plugin or plugin-channel, please report this in issue taconi/plugin-channel#42 |
I think around 1 or 2 more people now has to be given access on maintaining micro sometime. Micro may be considered stable or usable enough with some people like me, but there are still a lot of places that can be improved. The places that can be improved may be considered big or convenient with other users even if they are small. A lot of time is spent on maintenance and one maintainer may have less experience on some parts, so I do not think only having added 2 maintainers is enough. Maintenance does not have to be done fast but there may at least be progress in issues and pull requests instead of nothing happening in a period that is too long, even if there will be pull requests that are properly not accepted. Specific rights or roles cannot be given on personal repositories so the repository has to be moved to the organization. I have not read documentation much but I do think assigning writer and triage roles at organization level may be appropiate. People assigned triage role can at least manage issues in other repositories. There seems to be differences with the tcell fork in the organization so I do not know what can be done with it. I do not know if some will still be interested but I think the people @JoeKar mentioned are appropiate with the tasks that were mentioned. I think these also have to be considered:
I apologize for the long text but I wrote this comment thinking it may help with proceeding the discussion, and understanding why things mentioned in the thread would be done. |
I assumed that even with two people it would be hard to deal with the (legacy) issues.
Yep, moving |
@zyedidia
This issue shall be understood as a general request to officially support you and your project
micro
.Currently we've a lot of issues and PRs open, but no capability to get them into an sufficient order. What I mean is, that maybe all or some specific people currently active in trying to support here will receive the right to add (existing) labels and maybe some priority (milestone) handling to been as efficient as possible to not doing things twice and get the things sorted in the right order.
micro
is a very nice editor and has very interesting approaches and it needs to be frequently maintained. :)The text was updated successfully, but these errors were encountered: