More classes of maintainer

[Herby G]

I actually do think moving tickets and issues from Trac to GitHub Issues is
a good idea, and would increase engagement for the project.

On Thu, Nov 2, 2023, 10:19 Perry E. Metzger <perry at piermont.com> wrote:

>
> On 11/1/23 21:54, Joshua Root wrote:
> > On 2/11/2023 12:32, Perry E. Metzger wrote:
> >> As an aside, as it stands, the rules situation with closed maintainer
> >> / open maintainer is kind of unpleasant already. For example, I'd
> >> like to be able to indicate that I'm happy with anyone making
> >> reasonable changes to my ports on their own without waiting three
> >> days for me, but there's no way to do that, because "open maintainer"
> >> really means "three day timeout" just like closed. It would be nice
> >> if we had some sort of larger set of gradations for what people
> >> prefer, from "I handle all commits on this, period" to "if you have
> >> commit access and want to help, don't ask, just do it."
> >
> > A reasonable idea. I'd say that at some point you become less of a
> > maintainer and more of an interested party, but a list of people who
> > would just like to be Cc'd on the tickets and PRs for a port isn't a
> > bad thing to have.
> >
> > We seem to have somewhat different experiences, as the reason I
> > removed openmaintainer from some of my ports was that it seemed to be
> > interpreted more like "commit whatever you want without asking." So
> > being able to set expectations more clearly would be nice.
>
> For most of my stuff, I don't want to get in the way of trivial updates.
> If that just makes me an "interested party" so be it. What process would
> work here?
>
> >> As another aside, we also have a ton of ghost maintainers who never
> >> respond but whose name being on the port means you have to
> >> ritualistically wait three days for a reply you know will never come.
> >
> > This is of course what the Port Abandoned procedure is for.
> > Regrettably however, it also involves a three-day wait. :)
>
> The problem is, with separate trac and github stuff, there's now more
> friction on those tickets, and I don't think it happens very much in
> practice. Maybe part of that might be an indication that it's time to
> move the ticket system to github, and the other trac pages into a github
> wiki.
>
>
> Perry
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20231102/0028c773/attachment.htm>