In the past year most of the contents of FontForge's contrib directory were either removed from the repo or pulled out of the release build process. That was not out of skepticism about external contributions in general (I don't think), it had more to do with what had wound up there. contrib had become a place to put "fragile" projects that mixed C and python interfaces, and the move to GDK had altered the cost/benefit ratio against them.
I've made noises in the past about creating a robust "plugin" system that would allow "outside" contributors to deliver their own functionality through python modules (installed with pip, for example). That's still a worthy goal but a) it hasn't happened (yet?) and b) such a system still relies on users being able to find what they need. So it would be nice to have something concrete in the mean time.
Anyway, I'm opening this issue to suggest and start a discussion about some conventions for accepting contributions to be shipped with FontForge. Here are my thoughts:
- I think there has been some mild resistance in the past to adding scripts for things that could be added in C code without too much trouble. I suggest we just warn contributors that "we" can implement pieces of their contributions in C and remove their work as we see fit in the future and not worry about it beyond that.
- Acceptance into
contrib should be based on the combination of:
a. General applicability of the functionality
b. Code quality
c. Engagement of the contributor at the time of contribution. (This is a weak indicator of likelihood of future engagement, but it's something.)
Code quality is, of course, something that can be improved through engagement.
- I support a convention of each contributed tool having its own sub-menu under "Tools", so that FontForge's (in effect) mandatory contributions don't eat up a lot
of menu space, but each contribution has its own area.
- I also support adding default hotkeys for the more useful contributed functions, using more or less the same decision process we would when deciding on hotkeys for "native" menu options.
These questions are newly relevant because of @linusromer's offer in #3216. After seeking input from other FontForge users that tool has evolved into https://github.com/linusromer/curvatura, which I personally think is very close to meeting the bar for release in FontForge's contrib directory. It definitely adds functionality that has already been requested, and does so in a way that isn't compromised by being in script form. (That is, if we add hotkeys for it. @linusromer has some suggestions about those here.)
Therefore I suggest we discuss this a bit, and if we come to an agreement we either invite @linusromer to submit a PR, or construct some infrastructure that allows our build process to pull contributions from their own repositories. (If we do the latter we might want to request some level of access to the outside repo for some or all team members.)
In the past year most of the contents of FontForge's
contribdirectory were either removed from the repo or pulled out of the release build process. That was not out of skepticism about external contributions in general (I don't think), it had more to do with what had wound up there.contribhad become a place to put "fragile" projects that mixed C and python interfaces, and the move to GDK had altered the cost/benefit ratio against them.I've made noises in the past about creating a robust "plugin" system that would allow "outside" contributors to deliver their own functionality through python modules (installed with
pip, for example). That's still a worthy goal but a) it hasn't happened (yet?) and b) such a system still relies on users being able to find what they need. So it would be nice to have something concrete in the mean time.Anyway, I'm opening this issue to suggest and start a discussion about some conventions for accepting contributions to be shipped with FontForge. Here are my thoughts:
contribshould be based on the combination of:a. General applicability of the functionality
b. Code quality
c. Engagement of the contributor at the time of contribution. (This is a weak indicator of likelihood of future engagement, but it's something.)
Code quality is, of course, something that can be improved through engagement.
of menu space, but each contribution has its own area.
These questions are newly relevant because of @linusromer's offer in #3216. After seeking input from other FontForge users that tool has evolved into https://github.com/linusromer/curvatura, which I personally think is very close to meeting the bar for release in FontForge's
contribdirectory. It definitely adds functionality that has already been requested, and does so in a way that isn't compromised by being in script form. (That is, if we add hotkeys for it. @linusromer has some suggestions about those here.)Therefore I suggest we discuss this a bit, and if we come to an agreement we either invite @linusromer to submit a PR, or construct some infrastructure that allows our build process to pull contributions from their own repositories. (If we do the latter we might want to request some level of access to the outside repo for some or all team members.)