[Request & Discussion] Extended rights for volunteers to help supporting your micro project

[JoeKar]

@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. :)

[RichardFevrier]

I totally agree with @JoeKar.
Actually a lot of PRs open with people behind who took some of their time and deserve at least some communication 🙂
We are a lot to love this project ❤️ and hope that it continues to grow in a good way 😌

[zyedidia]

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.

[pallaswept]

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.

[JoeKar]

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.

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:
Since you're one who is very committed to the project what do you think about it?

[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 ;)).

[dustdfg]

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

[dustdfg]

@dmaluka @JoeKar
Hello! How do you manage your version that includes all the not merged PR's? Just bunch of merge commits?

[JoeKar]

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:
Friendly reminder, since nothing really changed so far. 😉

[dmaluka]

@dustdfg

How do you manage your version that includes all the not merged PR's? Just bunch of merge commits?

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.

[JoeKar]

Before we end up in more or less the same situation again after having the capabilities of labels/milestones and what ever.
How about directly adding merge rights and extended issue rights for at least some more trustworthy people (I don't count myself here 😉)?

I've still the trust that micro will benefit from combining all of our efforts/time from every supporter.

[dustdfg]

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:

1. Start using Triage role
2. Separate branch where those who have Writer role will be able to push. It will be the only place where people with Writer role will be able to push...

[dustdfg]

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 ;)).

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...

[dustdfg]

One more PR that could be just merged #1838 (Maybe with a bit of syncing color with statusline)

[JoeKar]

It looks like now micro is a repo of @zyedidia and doesn't belong to https://github.com/micro-editor organization.

...but would fit there the best. Additionally the updated forks of tcell and json5 would be perfectly placed there. The organization would allow the best maintainability.

It's now up to @zyedidia to carefully decide what's best for micro.

[RichardFevrier]

It's now up to @zyedidia to carefully decide what's best for micro.

Or it can be ended by creating a new repo (eg. micro-next) and fix the root problem of having a single maintainer.
And then grabbing every interesting contribution, etc...

[taconi]

From what I've read in the comments, I believe the consensus would be:

• Put the editor's source code in an organization
• Create positions in that organization for administrators and maintainers
• Add people from the community who are willing to do so

This would decentralize some functions such as maintaining the source code, accepting pull requests, creating labels/milestones.
These functions would no longer be the responsibility of just one person, but of all the people who use the editor and who are already involved in improving it.

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?

[Andriamanitra]

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.

[zyedidia]

I’m sorry for my non-presence and lack of availability. I think it’s time to add some maintainers to the project to help out. I think @JoeKar and @dmaluka would make good candidates to start. Please let me know your thoughts. Thank you for your patience and understanding.

[dustdfg]

@taconi maintains alternative plugin channel so I think he can be used for merging and maintaining original plugin repo

[JoeKar]

I think @JoeKar and @dmaluka would make good candidates to start.

Thank you, I'm honored. @dmaluka is definitely a safe bet too!
I can only speak for myself and can already predict, that some more people to support are necessary. Especially when we deal with the stack of past issues (currently 780 issues and over 100 PRs). I assume that our free time isn't enough to handle that 😄

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.
There is already a lot of intention visible.

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 micro. 😃 👍

[dmaluka]

I think it’s time to add some maintainers to the project to help out. I think @JoeKar and @dmaluka would make good candidates to start.

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.

[zyedidia]

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!

[taconi]

Do you have any prediction on when the repository will be migrated to the micro-editor organization or will it not be done?

[dustdfg]

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

[taconi]

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.
But for what reason will the editor code remain outside the organization?

[taconi]

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