Hello Bron, The statement of producing changes without user-visible effect, which break software, cannot be attributed only to me.
In the past proposed changes were pending for years until they were not anymore straight forward applicable to upstream code. Then I was asked to adjust my changes, so that they can be applied. In one case I adjusted my changes so that they can be applied towards the current code, which took a lot of time, then they were discarded, as a different approach for the addressed problem was seen as more viable. In other cases I stated that at the time I proposed the changes, they were good (applicable towards upstream), and I do not see me doing the proposed changes again. As nobody was willing to adjust the proposed changes, so that they can be applied to the code upstream at the time the code review was done, the proposed changes were rejected. If I name this a broken process, this can be perceived as demotivating. The contribution process is described on a third place in CONTRIBUTING.md: “One of the committers should review it soon.” I objected at https://github.com/cyrusimap/cyrus-imapd/pull/3594 that the word soon is included, asking from when on review will happen soon. Greetings // Дилян From: Bron Gondwana via Devel <devel@cyrus.topicbox.com> Reply-To: Devel <devel@cyrus.topicbox.com> To: Cyrus Developers (Public List) <devel@cyrus.topicbox.com> Subject: Re: On yrus IMAP Development Processes Date: 14/02/25 06:56:59 I had a pull request against an open source project accepted after 10 years once, so I guess... that long. More realistically, I guess the answer would be "be persuasive and produce overall improvements to the quality of life of the people who you're asking to review your work". You have 17 open Pull Requests, and some of your pull requests in the past have introduced bugs with changes which weren't adding user-value. You're asking others to do some hard thinking and prioritize reviewing your code over whatever else they're doing. That's a fair thing to ask for, but message like this can really hurt your case. When it comes down to it, this is a persuasion game - even for me and I'm the employer of some of the people in place to review code, I still need to make a persuasive case that it's worth their time to review my work! And find a good time, and ask nicely, and maybe ping them again rather than just assuming they'll come back and check among all the other pull requests to review mine. It's a chilling read to look at https://newsletter.goodtechthings.com/p/the-threat-to-open-source-comes-from and see how things like "your process is broken" can mess people up. I get your frustration but also, man this is not a good way to encourage any of the maintainers to give higher priority to your pull requests rather their own work on either their employer's priorities or things which are high priority in the project's significant-sized refactoring goals. Regards, Bron. On Thu, Feb 13, 2025, at 22:25, Дилян Палаузов wrote: > Hello, > > the Cyrus IMAP Development Process is described on two different places in > two different ways: > > At > https://www.cyrusimap.org/overview/cyrus_bylaws.html#iv-development-process > is stated that “The submitter of the code is responsible for ensuring that > the code gets reviewed by the core developers.” Submitters of changes have > absolutely no means to ensure that code gets reviewed, so they cannot be > responsible for this. > > The procedure at https://www.cyrusimap.org/imap/developer/process.html > suggests these steps: Create a pull request, wait for review (a quick note to > the mailing list can speed this along). > > In October 2024 I published > https://github.com/cyrusimap/cyrus-imapd/pull/5075 , which enhances the > CalDAV Admin HTML page ( http://server/dav/calendars/user/localpart@domain/ ) > by adding one more property (toggle to enable the server-side scheduling for > a calendar). This feature can be currently anyway applied by issuing > undocumented PROPPATCH requests. On 4 December I asked at > devel@cyrus.topicbox.com if that change can be integrated. > > So far nothing happened, which suggests that the suggested process: “Create a > pull request, then wait for review (a quick note to the mailing list can > speed this along)” is not working. > > A clearer criteria whether the procedures described at > https://www.cyrusimap.org/imap/developer/process.html do function, would be > to announce also how long one has to wait. Two years, more than three years? > > Greetings > Дилян > > ------------------------------------------ > Cyrus: Devel > Permalink: > https://cyrus.topicbox.com/groups/devel/T4b8a7a5d201419b6-Mda79a3bc2b7d12a4fd77d885 > Delivery options: https://cyrus.topicbox.com/groups/devel/subscription -- Bron Gondwana, CEO, Fastmail Pty Ltd br...@fastmailteam.com Cyrus / Devel / seediscussions +participants +delivery options Permalink ------------------------------------------ Cyrus: Devel Permalink: https://cyrus.topicbox.com/groups/devel/T4b8a7a5d201419b6-M934fdea2ed48347f19c335bd Delivery options: https://cyrus.topicbox.com/groups/devel/subscription
