Fwd: Proposal for PLC: Bugfix Accelerator 2023
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,
100% A. So glad to see this happening! :D That all core developers can apply to take on the work should make it completely fair vs. unpaid volunteer work. Anyone feeling sour about it can apply for the next round, once they meet the qualifications.
Thanks everyone for the hard work! -C
On Fri, Dec 2, 2022, 18:46 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
This involves me directly, so I must abstain.
Martin,
On Fri, 2022-12-02 at 19:46 +0100, Marc Jeanmougin 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
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
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
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
Hello Rene,
I consider it my job as a PLC member to read the proposed resolution and vote based on what it says. "It was discussed" doesn't really play into that. The discussion is not part of the resolution. To be clear, I didn't say "let's not do this." I said let's grow it instead of starting at the large size, start small, evaluate and get better. It's something new, and that's great, but we need to grow it smartly. I didn't want to say that without ideas, but what I included there are simply ideas. Happy to hear what other folks have to say there. Ted On Dec 6 2022, at 10:28 am, René de Hesselle dehesselle@icloud.com wrote:
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
Inkscape Board of Directors mailing list -- inkscape-board@lists.inkscape.org To unsubscribe send an email to inkscape-board-leave@lists.inkscape.org
As a PLC member, I consider it my job to support the various groups in Inkscape and support the decisions made collectively by those groups. I do not consider it part of my job to contradict or insist that those who actively contribute in those groups bow to my personal preference for how things should get done, especially without taking the time to be a part of the discussions that lead to the ask.
I'm not sure what is trying to be avoided by making one developer do everything, but it sounds very much like a lack of trust- lack of trust in the developer groups decision to put forward three applicants, and lack of trust in the applicants themselves.
This is not a lack of trust I share. I have full faith in the developer team to see this process through as they proposed and discussed in meetings which could have easily been attended by anyone who wants to be part of designing the process.
If we are not going to attend, we should at the very least not stand in the way.
On Tue, Dec 6, 2022, 18:23 Ted Gould ted@gould.cx wrote:
Hello Rene,
I consider it my job as a PLC member to read the proposed resolution and vote based on what it says. "It was discussed" doesn't really play into that. The discussion is not part of the resolution.
To be clear, I didn't say "let's not do this." I said let's grow it instead of starting at the large size, start small, evaluate and get better. It's something new, and that's great, but we need to grow it smartly. I didn't want to say that without ideas, but what I included there are simply ideas. Happy to hear what other folks have to say there.
Ted
On Dec 6 2022, at 10:28 am, René de Hesselle dehesselle@icloud.com wrote:
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
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
I vote C.
I share Ted's concerns about jumping in with such a "grand" first attempt. However, I'm sure some of that is based on different reasoning. I guess for me, I have to say that I don't see what the issue is with a smaller "trial run". Why not try 1 person for 1 month of work for this first attempt? Per CR earlier in the discussion "anyone feeling sour about it can apply for the next round". If we learn the lesson that the original proposal was correctly scoped, we're not out anything other than the release getting slightly delayed. If a 1 person trial shows the right amount of promise, there's nothing stopping putting forward a second proposal for the other 2 for a month of work each immediately after (I'm saying for the same release). I'd be thrilled if we could tighten up our release windows as well as release quality with paid work.
1) I'd be happy to see this re-proposed/updated with a smaller budget/scope for an initial attempt at such an effort. Something like what I mentioned above. Seriously, if 1 person for 1 month works great, I'd be all about immediately going for the other 2 for another month.
2) If you want to sway me to jump in at the currently proposed numbers (devs and budget), my suggestion would be to amend the proposal so that they will each be livestreaming the entirety of said contract work and all ~160 hours each will be publicly archived or something of that nature that helps make it so there is more accountability/tangibility to the value of the effort.
Cheers, Josh
On Fri, Dec 2, 2022 at 10:46 AM 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
Hey PLC,
From reading the responses and hearing some back channel about this vote, I'd like to hold a meeting to discuss this proposed project and some other PLC related matters like holding an election now that we've got all the votes!
Please fill our your availability for a call for next week:
https://framadate.org/xghzzPLXdQUIftIE
I'm cc'ing Jonathan as he has some extra context and thoughts on the issue of the current vote.
Please let me know if you are unavailable next week, or reach out to me privately if there is anything you would like to speak about.
Thanks, -Pono
On Fri, Dec 02, 2022 at 07:46:01PM +0100, Marc Jeanmougin 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
Didn't get a lot of response for this week on the poll. So I'll check in next week to see if there is a better time to get everyone together.
Sorry for not sending this out sooner, and have a good weekend! -Pono
On Thu, Dec 08, 2022 at 12:14:45PM -0800, Daniel Pono Takamori wrote:
Hey PLC,
From reading the responses and hearing some back channel about this vote, I'd like to hold a meeting to discuss this proposed project and some other PLC related matters like holding an election now that we've got all the votes!
Please fill our your availability for a call for next week:
https://framadate.org/xghzzPLXdQUIftIE
I'm cc'ing Jonathan as he has some extra context and thoughts on the issue of the current vote.
Please let me know if you are unavailable next week, or reach out to me privately if there is anything you would like to speak about.
Thanks, -Pono
On Fri, Dec 02, 2022 at 07:46:01PM +0100, Marc Jeanmougin 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
On Fri, 2022-12-16 at 08:31 -0800, Daniel Pono Takamori wrote:
Didn't get a lot of response for this week on the poll. So I'll check in next week to see if there is a better time to get everyone together.
Sorry for not sending this out sooner, and have a good weekend!
Thanks Pono,
I became somewhat unavailable because everyone here got covid.
But I think this meeting is really important so I want to make sure I'm available for the times everyone can get round this table. Please let me know if you want to run another poll.
Best Regards, Martin Owens
I vote (a).
With 2 (a) and 2 (c) (and 2 PLC members involved), more discussion is needed on the topic. I see pono is suggesting a discussion around it which is a good idea :)
participants (7)
-
C R -
Daniel Pono Takamori -
doctormo＠gmail.com -
Josh Andler -
Marc Jeanmougin -
René de Hesselle -
Ted Gould