Mislabling of legitimate fixes and contributions as AI Generated Spam with no actual validation of utility of a fix / improvement

[KidScripty]

I believe that @naveensingh has repeatedly mislabled fixes / contributions that I have created as AI generated spam. I am not saying AI was not used to create content (filling in issue forms, which they themselves have admitted they are too lazy to fill in FossifyOrg/Clock#338) or for code generation in some cases, however this is a standard part of a modern development workflow and everything has been checked with due diligence before creating the pull requests.

I drafted this pull request: FossifyOrg/Clock#364 where they have stated that the unit test created "is not testing the correct part of the code" that causes the bug which has been reported here: FossifyOrg/Clock#293

The test function written in the pull request called: testBugScenario_StaleAlarmFromDBGetsRescheduledIncorrectly aims to reproduce a bug which I have identified to be partly as a result of this function due to isToday not being recalculated: https://github.com/FossifyOrg/Clock/blob/main/app/src/main/kotlin/org/fossify/clock/helpers/AlarmController.kt#L37

The pull request introduces unit tests to simulate when an alarm is restored from the DB, isToday() was returning false (even though it should return true in some cases). This helps to simulate the issue.

I believe that this unit test correctly identifies part of the issue however it has blindly been dismissed as AI generated spam when it adds significant value in having a consistent way to reproduce the issue as well as helping to validate a fix. I opened the pull request as a DRAFT and would be open to feedback to improve or add further unit tests, however it was closed and rudely dismissed as incorrect without due diligence. Nowhere in the pull request did I stipulate that modifying rescheduleEnabledAlarms would be the area that should be changed to fix the issue. The fix should be a check somewhere to update the isToday value on some alarms prior to calling this function, however unit testing this area of the code and finding ways to consistently reproduce issues like this adds significant value. Additional testing could be added to validate updating isToday value behaviour also. When it comes to unit testing, the more meaningful coverage the better! Coverage is currently extremely low.

For however long this project has existed, even given how crucial having a working non-buggy alarm is for users, no one has decided that adding unit tests to validate this behaviour should be a priority. These bugs could literally result in people missing important events in their lives! This should be a priority. Similar logic was applied to another suggestion #805 about adding a way of excluding the app from some android battery management killing functions (which would also result in missed alarms). However @naveensingh again dismissed this suggestion with the justification of "it differs from vendor to vendor and gets messy over time", even though there is a consistent Android API way to do this that does not differ from vendor to vendor described here: https://developer.android.com/training/monitoring-device-state/doze-standby#support_for_other_use_cases. The problem with this project is, no one person knows everything and there should be a fair discussion before a conclusion is made on something. Instead, if the owner disagrees or has an opinion which differs from the original poster, it will be closed instantly, even to the detriment of the users.

It also discourages what could prove to be valuable contributions over time which would result in more capacity for improvements across the Fossify product suite which are a huge workload and difficult to manage for one person. I do give big props to @naveensingh for all the work that has been done so far.

For the record I have spent 20+ hours over the last few days getting to grips with the code base of Fossify clock, setting up local build pipelines, understanding, fixing and testing various bugs all of which has been met by someone blindly closing pull requests thinking that I am just AI generating some garbage. I did this to ensure I can have a working alarm that isn't going to fail for some weird reason and help to improve what seems like a decent open source project.

Similarly this pull request FossifyOrg/Clock#363 was dismissed as "not being the correct fix" when testing proved it to be sufficient, and no alternative suggestion was provided as to what the "correct fix" may be. I have since taken a different approach FossifyOrg/Clock#365 to fix the same issue, which provides an alternative solution (Absolutely no AI was used in this case).

I am requesting a fair assessment of contributions, without this bias and at least a meaningful justification as to why it isn't if the owner believes otherwise.

[tswistak]

As I can somehow agree that Fossify's management isn't good, I think you missed the point of why your contributions have been dismissed.

Similarly this pull request FossifyOrg/Clock#363 was dismissed as "not being the correct fix" when testing proved it to be sufficient, and no alternative suggestion was provided as to what the "correct fix" may be. I have since taken a different approach FossifyOrg/Clock#365 to fix the same issue, which provides an alternative solution (Absolutely no AI was used in this case).

Here you've just proved that your original solution was just a dirty quick fix. You shouldn't be surprised that code contributions like this are rejected. Fixes like this would work in startup projects while you're crunching because the release is in one hour. But not in slow-paced, stable projects.

I drafted this pull request: FossifyOrg/Clock#364 where they have stated that the unit test created "is not testing the correct part of the code" that causes the bug which has been reported here: FossifyOrg/Clock#293

You've created a PR for the issue that has an assignee, and you're surprised that it has been closed? I know that there are hundreds of issues assigned to Naveen (which is, in my opinion, the primary example of bad management here), but as a contributor, you should respect it. If this were an issue assigned to me, I'd be, slightly speaking, irritated. You could just write in the original bug report something like hey, I have a solution for this, can I provide a bug fix? and wait for the reply.

Also, my personal opinion (not quoting any contribution guidelines): if something isn't my project or a project where I'm on the team, I shouldn't do a draft PR. Because it blocks development, and nobody from the core team will know if this will ever be finished. PRs should only be submitted for the finished job.

however it has blindly been dismissed as AI generated spam

Contribution guidelines state clearly that AI-generated pull requests will likely be rejected. You could at least pretend it wasn't AI-generated and remove the obviously AI-generated code comments. I've been working in IT for several years and never met a living human who would write such detailed comments unless forced to. For example:

    /**
     * Test basic behavior: current time is 9 AM, alarm is 8 AM
     * Should be marked as TOMORROW since alarm time has passed
     */
    @Test
    fun testAlarmAfterCurrentTime_ShouldBeTomorrow() {
        val alarm = createAlarm(timeInMinutes = 480) // 8:00 AM
        val currentTime = 540 // 9:00 AM

        updateNonRecurringAlarmDay(alarm, currentTime)

        assertEquals(TOMORROW_BIT, alarm.days)
    }

Every developer knows that unit tests themselves serve as documentation - title + arrange with assertion should tell all about what's being tested. It really smells like GPT/Claude/Raptor/whatever. Also, other documentation comments in your PR feel very extraneous, like something that an LLM generates.

As a side-note: I, personally, don't see anything bad in using AI for help during coding. But we should always review what has been generated. Additionally, if we're working on someone's project, we should respect the contribution guidelines. If they say "no AI", at least do your best in pretending it wasn't AI.

[KidScripty]

As a side-note: I, personally, don't see anything bad in using AI for help during coding. But we should always review what has been generated. Additionally, if we're working on someone's project, we should respect the contribution guidelines. If they say "no AI", at least do your best in pretending it wasn't AI.

So are you saying that I didn't review what was generated in this case then?

[tswistak]

It's a simple fix which was tested and produces no side effects / inconsistencies. I still stand by that fix being a legitimate fix.

Android devices come in numerous different screen sizes. Have you checked them all to be sure that you haven't destroyed the layout on smaller devices? Size change to explicit value should always be a last resort in any UI work, not only mobile.

This issue has been assigned to him since November 4th

We may disagree with the fact of the assignment, but we should respect it. I'd consider assigned == in progress.

Draft pull requests for one idea of an implemention don't block an alternative implementation being developed at all. It's a place to share ideas, comment directly on lines of code, iterate and improve.

Issue comments are a better place to share ideas. Maybe if your draft contained something more than just unit tests, it wouldn't be closed, but it didn't contain any actual fix. And don't get me wrong - IMHO there should be unit tests. But it doesn't justify creating a draft PR for the fix, which didn't contain a fix.

Do you agree that there is any difference between "AI-generated pull requests" and AI generated code comments?

I agree, but it just made your code look AI-generated. To be honest, this code would be fine without those comments, as they haven't added any useful context. The purpose of extracting functions was clearly visible, and the test code was self-explanatory.

How is this significantly better than just opening a draft pull request that, instead of explaining the potential solution in plain english which is ambiguous, showcases an actual implementation which would be fed back / interated on?

Again, it's to respect the management decision that the issue has already been assigned to somebody.

So are you saying that I didn't review what was generated in this case then?

I don't say it. But you should know that for the other side, seeing LLM-generated comments is the best way to verify that someone just told Copilot to generate the code and pressed "Keep" blindly.

[KidScripty]

Android devices come in numerous different screen sizes. Have you checked them all to be sure that you haven't destroyed the layout on smaller devices? Size change to explicit value should always be a last resort in any UI work, not only mobile.

I respect that justification, and if I read that in the pull request then it would have given more context on the direction of alternative fix. The new fix doesn't change that width value as I'm sure you can see.

We may disagree with the fact of the assignment, but we should respect it. I'd consider assigned == in progress.

Would you agree that the contributions guidelines should stipulate things like this and provide more clarification on the AI policy with regards to things like code comments? How was I supposed to assume assigned == in progress given so many things as assigned and cannot be worked on in parallel. From my perspective there are 0 aspects of the contributions guidelines that I have broken when it comes to those closed pull requests. Considering the contributions guidelines as so ambigous, there should be a certain level of respect and guidance given on pull request comments.

I cannot be expected to assume things like AI-generated pull requests will be rejected means no AI generated function annotations! Also, it's a small thing which means that it can be removed with a simple comment.

I agree, but it just made your code look AI-generated. To be honest, this code would be fine without those comments, as they haven't added any useful context. The purpose of extracting functions was clearly visible, and the test code was self-explanatory.

So what if the code looks AI generated, I wrote the functions and then generated the annotations. I also manually refactored the existing functions to make them testable, all of which you seem to agree are good things. The biggest disconnect for me is on the previous pull request for the stopwatch layout issue which was closed as not the correct fix, fair enough, your justification makes sense. But that means that there is always some feedback that can be given on a potential fix to ensure undocumented standards, best practices etc. This is the entire point of a pull request / draft pull request. Yet I make a draft pull request, easily someone could give feedback saying, remove unneccessary annotations and we could continue from there. Instead it gets closed for a trivial reason which was not properly documentated in the contribution guidelines!

So there is a potential fix for an issue, someone tries to implement it. When do you think the feedback should be done? Even if a plan for an implementation was discussed in the issue comments, the actual implementation still needs to be reviewed.

[KidScripty]

Issue comments are a better place to share ideas. Maybe if your draft contained something more than just unit tests, it wouldn't be closed, but it didn't contain any actual fix. And don't get me wrong - IMHO there should be unit tests. But it doesn't justify creating a draft PR for the fix, which didn't contain a fix.

Based on this, you are saying that no feedback should be given until an entire issue is fully resolved via pull request reviews, which directly contradicts the maintainers having some underyling idea of how a solution should be developed according to best practices. A contributor spends a long time and more effort developing something all the way to completion and then the fundamental approach is questioned. Why can't things be discussed and fed back on in the form of draft pull requests in order to collaboratively arrive at a better solution?

That's what the request changes button in the pull request review UI is for!

[KidScripty]

Literally all I am asking for is for pull requests raised to be reviewed properly and not blindly dismissed. Mine was blindly dismissed and the only thing you found wrong with it is an AI generated comment that could be easily deleted.

Please allow people to raise draft pull requests and give feedback if it's ok and they can continue with implementing a solution (given it's not already assigned to someone else) and then request further review accordingly. Obviously not to the point where it's taking up a huge amount of peoples time to review trivial changes (for example implementing a obviously not well thought out solution and then asking for review). In this case, my draft PR on the tomorrow never comes bug was a good step forward objectively minus a small AI generated comment.

[naveensingh]

I didn't want to dignify your behavior even more with a response, but for the sake of clarity, here are your dismissed contributions:

1. Add "Background Reliability" check and Battery Optimization whitelist prompt 🐇 #805 - I already answered there why it's not a good solution and why it won't help on those specific devices. The API allowing you to ignore battery optimizations is for special use cases. It is not necessary in Fossify Clock because alarms set via the setAlarmClock() are not affected by Doze. This is mentioned in the documentation page you linked above. One can't predict what the optimization layer added by Samsung and other vendors will do or not do based on that AOSP API if they aren't respecting critical alarms. The current implementation already has issues that need to be fixed before we can blame it on vendor optimizations.
2. Feat: Automated Reliability Testing with CTS Inspired Logic #806 - Again, CTS tests don't belong here and are for testing device behavior (see https://source.android.com/docs/compatibility/cts). I'm aware that you have since updated your proposal to be CTS-inspired-something that I won't be reading now.
3. Add VS Code Dev Container for reproducible development environment #807 - Android Studio is the official/recommended tool for the job. Sure, some people might use VSCode, and some prefer CLI, but those are alternative workflows that don't need to be officially supported in this project because everything comes with a maintenance cost.
4. Fix: Stopwatch lap times unseparated Clock#363 - The problem was that columns weren't properly spaced. You were fixing that by increasing the column width instead of adding space between columns.
5. Fix: tomorrow never comes Clock#364 - The bug report is titled "tomorrow never comes" meaning the scheduled alarms for tomorrow keep moving to now + 1 day. You were trying to fix that by checking if we should be rescheduling those affected alarms. Precisely, your test (thus the fix to be implmented) was trying to (incorrectly) prevent rescheduling of stale alarms, but given how alarms are stored in this app, skipping rescheduling of alarms where the "scheduled time" is in the past today means you will also skip scheduling alarms for tomorrow for times that are in the past today. If you spent some time investigating the problem, you would know this, but instead, you appear to be focused on forcing best practices by doing TDD in a project that doesn't have tests.

So, they weren't "dismissed" just because they seem AI-generated or because it's a draft PR or because the issue has an assignee (see this and this). They are being rejected for all those reasons and the reasons mentioned above. I have nothing against AI itself, but how you are using it. Personally, I have my fingers crossed for AGI by 2030 and O'Neill cylinders by 2080.

Also:

• In two of your PRs, you have checked "I have updated the changelog", but did not touch the CHANGELOG.md file. The recurring pattern makes me think you are not careful with your AI-assisted contributions (including the AI-filled forms), and making me review things you haven't put much thought into.
• I probably wouldn't have reviewed Fix: tomorrow never comes Clock#364 until it was marked ready, but you asked for my opinion by mentioning me in your comment there. Personally, I think a reasonably good PR is one that moves the needle in the right direction at least somewhat and does not require the reviewer to come up with the core solution.
• There's an intentionally blunt rule in the contribution guidelines that you did not read/follow:
  • PRs must be well-researched, thoroughly tested, and production-ready.
  • No bare-bones or incomplete PRs.
• Regarding misclassification, maybe you did write the code yourself, and maybe you did write your issues and comments too, but if you make something look like a duck, swim like a duck, and quack like a duck, then for all intents and purposes, it will be hard to mistake it for a giraffe.

[KidScripty]

I'm sure you think you behaviour is completely justified which is obvious by the fact you haven't responded directly to the examples I have given of your actions that I have suggested were unjustified.

#805 - I already answered there why it's not a good solution and why it won't help on those specific devices. The API allowing you to ignore battery optimizations is for special use cases. It is not necessary in Fossify Clock because alarms set via the setAlarmClock() are not affected by Doze. This is mentioned in the documentation page you linked above. One can't predict what the optimization layer added by Samsung and other vendors will do or not do based on that AOSP API if they aren't respecting critical alarms. The current implementation already has issues that need to be fixed before we can blame it on vendor optimizations.

This response re-iterates the point I made about instantly closing things without proper discussion or considering alternative viewpoints. Since the answer you gave on why you think this is not a good solution, I left a follow up comment which acknowledged the point you made about setAlarmClock() not being affected by doze. The point about not being able to predict the behaviour of the optimization layer I believed was worth discussing given that there is common behaviour between vendors kill apps based on "buckets" that can be controlled ACTION_IGNORE_BATTERY_OPTIMISATIONS_SETTINGS intent. They usually respect critical alarms, but the app may be killed by the optimisations. You closed the issue immediately after you left your original response, indicating that you would not participate in any follow up discussions and you weren't open to considering it any further, not giving people a chance to response which is rude and is what I also assume will happen with this discussion.

#806 - Again, CTS tests don't belong here and are for testing device behavior (see https://source.android.com/docs/compatibility/cts). I'm aware that you have since updated your proposal to be CTS-inspired-something that I won't be reading now.

Again this suggestion was about adding more testing with an integration testing style approach where vendor behaviours around killing apps for battery optimisation could be simulated and lead to a better approach of building a more resilient alarm which is less likely to fail. However it proved to be another example of, just close this issue without properly considering it. I will say admit, that in the first draft of that issue there was some confusion around leveraging CTS tests directly vs using the logic that is contained within those specific tests to test app alarm logic and resilience against battery optmisations before and after moving the app into different "buckets" based on the BATTERY_OPTIMISATIONS intent. As I made clear in the original post of this discussion, I don't believe a fair consideration of the proposal was given.

#807 - Android Studio is the official/recommended tool for the job. Sure, some people might use VSCode, and some prefer CLI, but those are alternative workflows that don't need to be officially supported in this project because everything comes with a maintenance cost.

That's fair enough, I agree with that, you could have just said that in the issue discussion and I have no problems with that. Instead you just said : "Android app development is primarily and officially done on Android Studio. You can download it here." and closed the issue instantly after giving no context like you did above, and again no chance for anyone to respond.

FossifyOrg/Clock#363 - The problem was that columns weren't properly spaced. You were fixing that by increasing the column width instead of adding space between columns.

Increasing the width of the column did fix the issue as was demonstrated by the testing I did and the screenshots of before and after that I provided. If the width of the box is larger than the maximum width that the text will take up then it effectively provides margins within the box itself. @tswistak Pointed out that increasing the width could have implications on smaller devices vs other approaches which I do agree with however any layout change regardless of changing width vs adding margins could possible have issues on some devices but opting for a non width changing approach doesn't substitude the need for thorough device testing. Referring to this pull request: FossifyOrg/Clock#218 I see that considerable amount of layout changes were made including modifications to dimensions similar to the fix suggested for the stopwatch issue and there is one test screenshot on there. I'm not saying that's due diligence wasn't done there, but it's not any less risky that the change I proposed. Again, you could have said exactly that as a comment in the pull request to give some indication as to why you didn't consider that the correct fix but all you said was "Increasing the width isn't the correct fix." and closed the issue instantly. This is one of a few examples where you could have had the basic decency to put helpful comment. I then implemented an alternative fix, assuming you would prefer an alternative approach which involved adding margins which is here. I hope you at least have the decency to review this properly, however based on what I have seen so far, I wouldn't be surpised if you just close it FossifyOrg/Clock#365

FossifyOrg/Clock#364 - The bug report is titled "tomorrow never comes" meaning the scheduled alarms for tomorrow keep moving to now + 1 day. You were trying to fix that by checking if we should be rescheduling those affected alarms. Precisely, your test (thus the fix to be implmented) was trying to (incorrectly) prevent rescheduling of stale alarms, but given how alarms are stored in this app, skipping rescheduling of alarms where the "scheduled time" is in the past today means you will also skip scheduling alarms for tomorrow for times that are in the past today. If you spent some time investigating the problem, you would know this, but instead, you appear to be focused on forcing best practices by doing TDD in a project that doesn't have tests.

A fix could be developed for this without adding any unit tests, alternatively unit tests could be added to consistently reproduce the issue and then a fix could be developed and the associated tests could pass which would be considered TDD as you mention. The DRAFT pull request was an initial proposal which I did not mark as ready, however I did leave a comment which I tagged you in again hoping to start a discussion on useful unit tests to add to reproduce the issue. The comment I left was:

"@naveensingh In this phase I have added unit tests to reproduce the issue which causes the build to fail intentionally.
More tests could be added to verify different scenarios as described in the original issue report.
If you are happy with this approach I can then push the fix which will then cause the build to succeed and pass the test.
Otherwise if you are not happy with adding unit tests to reproduce the issue then I will create a separate pull request with just the fix."

As you can see I said "more tests can be added to verify different scenarious as described in the original issue report". I also said, if you don't want units tests then I would push the fix without tests. i.e Make a separate pull request, to the best of my ability that would solve the issue.

In two of your PRs, you have checked "I have updated the changelog", but did not touch the CHANGELOG.md file. The recurring pattern makes me think you are not careful with your AI-assisted contributions (including the AI-filled forms), and making me review things you haven't put much thought into.

That is an incorrect assumption, I see you intentionally misquoted the PR checkbox description. The PR form template says:

I updated the "Unreleased" section in CHANGELOG.md (if applicable).

There is no guidance on what changes are deemed applicable to updating the changelog, and again you could easily just say in a pull request review comment "please update the changelog accordingly".

I probably wouldn't have reviewed FossifyOrg/Clock#364 until it was marked ready, but you asked for my opinion by mentioning me in your comment there. Personally, I think a reasonably good PR is one that moves the needle in the right direction at least somewhat and does not require the reviewer to come up with the core solution.

Opening a draft PR and the comment I left is directly seeking feedback from yourself as maintainer surely validates if the general approach is going in the right direction, which can then be iterated on and marked for review when ready as per a standard Draft PR -> PR process. If you didn't want any unit tests as part of the solution, then taking time to add more would be pointless. This is the key point I made in the original post about discussing what a good approach to solving a problem would be. In my opinion, any bug like this should be a huge motiviation to add unit tests in that area, by opening that draft pull request, I was testing to see whether you actually agree with that. This definitely moves the needle in the right direction, from 0 to 1+ unit tests around alarm behaviour!

There's an intentionally blunt rule in the contribution guidelines that you did not read/follow:
PRs must be well-researched, thoroughly tested, and production-ready.
No bare-bones or incomplete PRs.

This was a draft PR. The contribution guidelines are far from comprehensive. Where would you expect the discussion to take place on different approaches for a possible solution then? i.e Given the case of Unit tests + Fix vs Just Fix for alarm issues?

Regarding misclassification, maybe you did write the code yourself, and maybe you did write your issues and comments too, but if you make something look like a duck, swim like a duck, and quack like a duck, then for all intents and purposes, it will be hard to mistake it for a giraffe.

I did not claim to be anything but a duck. 🦆

[KidScripty]

@tswistak @naveensingh also regarding your comment about changing the width dimension not being a valid / correct fix. Check the pull request here: FossifyOrg/Clock#365

Look at the bug reproduction image. If you look at the column on the right for the total lap time, you can clearly see that the digits get cutoff when the lap time goes into the minutes so it's clearly not only a margin issue. The previous fixed width is objectively too small for the text. If it was only a margins issue then I would expect the middle column to be cut off by the right column but you would not then expect the rightmost column to be cutoff due to the additional space off to the right unless it was clipped by the parent container which I don't think is the case here.