Project Governance / External Contributions

[Nathaniel McCallum]

Given the recent announcement of the retiring of the MIT KIT
consortium, I would like to inquire about two aspects of the MIT krb5
project that seems somewhat undefined to me.

First, how will the project decide which features to adopt in the
future going forward? Previously, external contributors had recourse
by subscribing to KIT. This obviously had the problem that votes == $.
I am glad MIT is seeking to correct this. However, it is less clear to
me what the governance model will be going forward. For instance, who
will decide whether or not a certain feature appearing on the list will
be merged? Do organizations other than the Institute get a say in this
process?

Second, is there any plan to decentralize commit access to the project?
Again, without the KIT consortium, should difficulties arise in timely
patch review and approval, external contributors are entirely reliant
on the MIT for review and committing. Moving forward, will there be a
process by which proven external contributors can gain commit
priviledges (following an appropriate public review policy, of course)?

I think that the MIT has an opportunity here to demonstrate leadership
in open source project governance; and Red Hat is happy to lend its
experience in this area to this process.
_______________________________________________
krbdev mailing list ***@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev

[Greg Hudson]

Post by Nathaniel McCallum
Second, is there any plan to decentralize commit access to the
project?

Let me answer this question first: we are open to adding project
committers who aren't working for MIT. We would like all of our active
committers to bear a high level of project responsibility, including a
willingness to work on all areas of the code (or at least the Unix
code), to help with analysis of bug reports, to help with review of pull
requests, to participate in design discussions, to improve the
maintainability of existing code, and to enforce the project's coding
and version control practices.

Post by Nathaniel McCallum
First, how will the project decide which features to adopt in the
future going forward?

As before, these decisions will be made by the project's active
committers, weighing the benefit of new features against their
complexity and maintenance cost. To the extent that any organizations
have influence on these judgments, that influence will depend on the
organization's contribution to the Kerberos ecosystem--which might
include development contributions, downstream distribution, consulting
activities which give insight into user requirements, etc.

_______________________________________________
krbdev mailing list ***@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev