I assume that the quantity of developers is what is required to reasonably fix most of the bugs before release. I don't see much difference in hiring three developers for 10k each vs hiring one developer for 30k. Also, having a variety of bug fixers is preferable, because we get a broader range of experience, and everyone has their specialties. What may take one developer twice the time to fix may be easier for one of the others.

I say we should let the active developers decide how many people are needed. They will know better than the leadership committee.




On Tue, Dec 6, 2022, 15:28 Ted Gould <ted@gould.cx> wrote:
c. Other, I think we should hire one developer for bug fixes for the 1.3 release.

Generally, I feel like we need to figure things out here and going from zero to three is probably too much for us to track and keep up with it. I'm not sure if the whole thing is a good idea or not, but I do think it is worth trying, so we should try with one developer; then evaluate; and react to that in a future release.

That brings forward the problem of selecting who that developer would be. I'd suggest that we do a short Request for Proposals with a rather high bar for applying. For instance, I'd say we should make a requirement having three accepted merge requests since the previous release. I think that'd be enough to limit to folks who do not need mentoring oversight. And since we can easily contact all the folks who'd be eligible, we can make the deadlines rather short in time.

I also mentioned that I think we need some way to evaluate the success of the program, with bug fixing in software that is very difficult. What I think we should do here is take (hopefully we'll have by then, /me crosses fingers) our members and provide them with a survey after the release. This is something we could start doing after every release in the future. But this time we should add questions like "This release is higher quality than 1.2. (disagree/agree five step)" (I think we should have others as well, but that's not quite on topic).

Ted

On Dec 2 2022, at 12:46 pm, Marc Jeanmougin <marc@jeanmougin.fr> wrote:

Dear PLC,

*Background:*

Jonathan Neuhauser (@joneuhauser at Gitlab and chat.inkscape.org) is
submitting a proposal to hire three core developers for the equivalent
of a month of work each to fix bugs and regressions during the remaining
time until the 1.3 release. This proposal has been cleared by the SFC
(Pono and Karen) and received a favorable reception during the developer
meetings. The proposal is designed such that no (micro)management /
mentoring is needed (thus only trusted core developers were considered).
As the AI project explicitly targets outside contractors, this proposal
attempts to use our funds internally.

The complete proposal is appended; it contains all the details on the
selection process, persons, objectives as well as a personal remark by
Jonathan on the impact on the project's general atmosphere.

*Proposal:*

Voting is needed on the following items:

- hiring Rafal Siejakowski, Martin Owens and Tavmjong Bah as contractors
during the bugfixing season in order to fix serious bugs before 1.3 is
released,

- allocating a total of USD 34,200 as compensation for the three
contractors.

Details on the process are lined out in the attached document.

*Ballot:*

a. Accept the above items.
b. No, cease effort for Bugfix Accelerator 2023
c. Other: ______

Best regards,
_______________________________________________
Inkscape Board of Directors mailing list -- inkscape-board@lists.inkscape.org
To unsubscribe send an email to inkscape-board-leave@lists.inkscape.org
_______________________________________________
Inkscape Board of Directors mailing list -- inkscape-board@lists.inkscape.org
To unsubscribe send an email to inkscape-board-leave@lists.inkscape.org