Ted, I would like you to reconsider.
You have not brought forth any hard concerns or problems with the current approach, you just "feel like" it could be done differently. Please leave this up to the people who actually drive this initiative since you don't. Let us try it the way it was proposed, it has been discussed at length.
There are reasons why there are three people, Chris has explained that correctly. I'd like to stress that it's less risky than only one developer because they can help each other out and review each other's MRs - a good strategy to counter blockers along the road.
Am 06.12.2022 um 16:51 schrieb C R cajhne@gmail.com:
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 _______________________________________________ Inkscape Board of Directors mailing list -- inkscape-board@lists.inkscape.org To unsubscribe send an email to inkscape-board-leave@lists.inkscape.org