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.
>
> 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
>
>
> Dear PLC,
>
> *Background:*
>
> 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,
> _______________________________________________
> _______________________________________________
> _______________________________________________
_______________________________________________