Stream: Coq Platform devs & users

Topic: Only maintainers open issues?


view this post on Zulip Karl Palmskog (Aug 04 2020 at 22:22):

If only maintainers can/should open issues about Coq Platform inclusion, I think we are going to end up with a short list. Basically we will have to reach out and explain the platform to everyone, and many are on vacation and so on. Isn't it better to create issues and then just ping in maintainers?

view this post on Zulip Théo Zimmermann (Aug 05 2020 at 07:58):

Sure, that's perfectly fine. That's what Bas has been doing.

view this post on Zulip Michael Soegtrop (Aug 06 2020 at 10:28):

Karl Palmskog said:

If only maintainers can/should open issues about Coq Platform inclusion, I think we are going to end up with a short list. Basically we will have to reach out and explain the platform to everyone, and many are on vacation and so on. Isn't it better to create issues and then just ping in maintainers?

It is fine for everybody to create issues for inclusion and ping the maintainer, but I need the agreement of the maintainer to include it in the ticket, stating that (s)he has read the charta and understood the implications.

view this post on Zulip Michael Soegtrop (Aug 06 2020 at 10:32):

Btw.: I already suggested before to have two levels of the platform - a well maintained and long term trustable level 1 and a more relaxed but also more extensive level 2 which can also include betas, previews, convenient tools which are nice to have but would not kill a project if they become unavailable (say coq2html).

view this post on Zulip Théo Zimmermann (Aug 06 2020 at 10:42):

@Michael Soegtrop It's funny you mention this now since I just opened https://github.com/MSoegtropIMC/coq-platform/pull/19 which contains a reminder of these two tiers.

view this post on Zulip Karl Palmskog (Aug 06 2020 at 11:11):

"the maintainer" is often ambiguous. Quite a few projects are maintained on a "by-need" basis by a loose collection of people. I don't see how any of the commitment stuff can be meaningful without central management or funding.

view this post on Zulip Théo Zimmermann (Aug 06 2020 at 11:29):

When there is no one who is ready to commit, then we should simply not include the package.

view this post on Zulip Théo Zimmermann (Aug 06 2020 at 11:30):

Committed maintainers on fixed-term contracts is something else (which coq-community can help with).

view this post on Zulip Karl Palmskog (Aug 06 2020 at 11:30):

but what does "commit" even mean? Just ready to make some statement about committing?

view this post on Zulip Théo Zimmermann (Aug 06 2020 at 11:31):

Well of course, we do not request a signed agreement, but we expect some moral commitment that the package will keep being maintained for the foreseeable future.

view this post on Zulip Karl Palmskog (Aug 06 2020 at 11:31):

for example, if the maintainer is an academic, universities will not typically be willing to commit to anything on behalf of an employee without funding.

view this post on Zulip Théo Zimmermann (Aug 06 2020 at 11:32):

We don't ask people to sign anything, therefore they don't have to request permission from their employer.

view this post on Zulip Théo Zimmermann (Aug 06 2020 at 11:33):

I'm not trying to elude the funding question here (a very important one). Just trying to clarify what are the expectations to get into the platform as of today.

view this post on Zulip Karl Palmskog (Aug 06 2020 at 11:35):

I understand why, but well, my argument is that "moral commitments" are nearly devoid of (real-world) meaning. It may be better with some concrete (less empty) requirements, such as: project has been regularly updated since Coq 8.8, project has had regular tags/releases, etc.

view this post on Zulip Karl Palmskog (Aug 06 2020 at 18:20):

... based on the principle that past behavior predicts future behavior (but imperfectly)


Last updated: Jan 30 2023 at 12:03 UTC