RFC: New formalised process and joined maintainership of the PVP spec

[Herbert Valerio Riedel]

Hello CLC et al.

TLDR:

Do you, the CLC, have interest in a joined responsibility by
maintaining the PVP with a process/scheme (or some variant of it) as
outlined below?

----

In my function as a Hackage Trustee, my interest is to look after
Hackage's overall health, which involves educating users about Hackage
conventions and fixing up the occasional inaccuracies in .cabal
meta-data via editing.

One central convention which Hackage is built upon (together with the
CABAL spec) is the PVP. Moreover, the PVP as a common convention is what
makes the task of Hackage Trustee's feasible/manageable in the first
place.

However, the PVP has been traditionally hosted in a free-for-all wiki
page which everybody with a wiki account is able to edit:

https://wiki.haskell.org/index.php?title=Package_versioning_policy

while those changes are mostly well-meant, it's bad for a document which
is to serve as an important specification/guideline to have such a loose
change-policy.

There ought to be a proper process for accepting/rejecting edits,
including trail of discussion. In order to address this together with a
few other related aspects (transparent trail of discussion/decision,
UI-assisted review of changes, more convenient source-format, ...), and
inspired by GHC HQ revamping its change/proposal process, I took the
initiative and finally wrapped up (with help from Oleg) something I
started back in 2014 by setting up the

- https://github.com/haskell/pvp

repository to host the source & discussion/paper trail for changes, as
well as setting up the canonical new location at

- http://pvp.haskell.org/

hosted via GitHub pages.

This repo features the latest version of PVP from the wiki converted to
Markdown. The current stylesheet is what my limited CSS skills could
manage to come up with, and would ideally be aligned better with the
haskell.org style-guide.

----

The most important aspect of this is to clarifying the process for how
to make/propose changes to the PVP, and who's the formal maintainer of
the PVP.

I suggest to declare the CLC together with Hackage Trustees as the
formal maintainers. The motivation being, that Hackage Trustees
naturally represent the operational POV, as they have to actively
interact with Hackage, whereas the CLC is well suited to represent the
strategic long-term view, and is made up of diverse group of
stakeholders.

----

Also, by giving the PVP an easy to remember/type official-looking URL,
i.e. http://pvp.haskell.org, I argue, that this provides the PVP more
credibility as an official policy than it would being merely some random
wiki page.

I've also added a sign-post at the top of the current Wiki page to point
to pvp.haskell.org.

----

As for changes, I propose that proposals shall start in the associated
GitHub tracker, and ideally stay there. If a wider discussion is deemed
useful/necessary, extending to reddit/mailing-lists/whatever is
acceptable, while ensuring that the GitHub issue/PR links to all
relevant external discussion threads.

----

Moreover, the PVP being a versioning scheme ought itself to be versioned ;-)

Maybe a natural number (which could either be consecutive [1..], or a
date, e.g. 20160315), *or* we could even have the PVP follow the PVP
scheme self-referentially :-)

Also, include a concise version history at the end of the PVP, so ppl
can easily look up if there were important changes affecting them since
the last time they read the PVP).

----

Now, for the hard part. Deciding what to do about proposed
changes. Typos and other obvious fixes will be a no-brainer. To borrow
From the Rust RFC process, stuff that falls into `Rephrasing,
reorganizing, refactoring, or otherwise "changing shape does not change
meaning".` should be easy to sign off.

The interesting and tedious part will, of course, be controversial
changes, which is what makes it important to have a formally responsible
entity. I'd suggest a somewhat vague consensus based decision process:

Basically, if there's a general agreement that the change appears to
constitute a reasonable improvement over the status quo, and there's no
one who *strongly* opposes the proposed change. In this case we'd have
to look at the concerns the opposing parties have against the chance,
and see if there's any chance to resolve those.

In any case, there's 3 different outcomes from this process:

- accepted (due to consensus that it's a desirable change)

- rejected (due to consensus that it's clearly undesirable), it makes
little sense to re-propose the same proposal w/o some radical changes
(to the proposal, or the situation in the ecosystem)

- undecided/"meh" (due to lack of consensus or interest), this basically
is a weaker form of rejection, and means that the proposer should try
to make a stronger case to achieve a positive consensus

This is admittedly a possibly naive scheme, and I'm hesitant to
over-design this at this point. If this doesn't work out, one can always
just resort to some traditional voting scheme, but then everyone should
agree to honor the voting result and move on.

----

So, what do you think? Is this crazy talk? Critique? Suggestions?


Thanks for your attention so far!

-- hvr

[Michael Snoyman]

-1. I'm tired of seeing community processes in the Haskell world abused to push technically inferior solutions.

--
You received this message because you are subscribed to the Google Groups "haskell-core-libraries" group.
To unsubscribe from this group and stop receiving emails from it, send an email to haskell-core-libr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Eric Mertens]

I think it makes sense for the PVP to have a distinguished place and for changes/improvements to it to be protected by a process similar to that of the rest of the core libraries.

A common PVP is a critical element of a shared understanding of what we mean when we use version numbers and interdepend on each other's packages.

Using version number has flaws, but it's the best solution we have today. It makes sense that in addition to maintaining that core libraries that we'd also support the shared understanding that makes interoperation possible across releases.

Regards,

Eric

[Edward Kmett]

It does seem to fall under the sort of "community commons" that we typically concern ourselves with. We've already been consulted on whether to switch to RFC-like vocabulary, and the like, so formalizing that role a little more doesn't seem to hurt.

I'm weakly +1 from the standpoint that we're basically already doing at least that much.

I hope you don't expect an awful lot of active maintenance or enforcement of its guidelines though. For the former it has been remarkably stable over the years, and for the latter you may find it difficult to achieve consensus.

-Edward

--

[Dan Doel]

I'm also in favor of keeping the PVP in a more codified spot, and
moderating changes to it. It is integral to the way that Hackage is
actually organized, and I don't think it can be ignored without
changing the system to leave out Hackage and cabal all together.
Personally, I have no interest in getting rid of Hackage and cabal,
and I suspect there are many people who feel the same. So in that
light, I think it makes sense to lay out the details of how to
properly work in that ecosystem, for people who actually want to do
that.

I don't know that it needs to be the core libraries committee that
owns it, since I don't think we're in charge of all of Hackage per se.
But it's as good a group as any, I suppose.

-- Dan