GNUZoo Profile-Talk đşđ¸Clear The Air
I wanted to send a note to clear the air because I was really taken aback to see any mention
of "abuse." I want to be 100% clear: I have deep respect for you, your massive contributions,
and all the years of work you've put into maintaining PmWiki. There is zero hostility or abuse
intended on my end whatsoever.
I know we've had some spirited debates on the PmWiki and recently on the Media-Talk pages, and
maybe there's some lost translation or a cultural gap in how we communicate in writing. But
please know we are ultimately on the same team. My only goal in bringing up these feature
ideas, quirks, or bugs is because I love using PmWiki and want to help make the media handling
even better and more flexible for everyone.
I appreciate everything you do for the community, and I hope we can keep working together
constructively to make PmWiki more awesome.
Iâve told you before, and I genuinely mean it: I am constantly in awe of your deep technical
knowledge and how quickly you solve complex problems. When I've reached out in the past with
enthusiasmâcalling you a hero or marveling at how you figure things all outâit's because I
truly believe it. I've never meant to overwhelm you. I've just always wanted you to know how
much your brilliance is appreciated.
I meant it when I post a super hero emoji and text "đŚ¸ââď¸ Super Petko to the rescue again!" as
a sign of respect. I would not be able to fix it without your help. Listing you on the
"Programming Heroes" page (which you removed your image and text) is a sign of respect.
When I say to you "You are the greatest" I mean it and it is a sign of respect.
When I say to you "WOW How can you just know all this stuff!" I mean it and it is a
sign of respect. Petko, you are amazing. I am saddened that you could misinterpret my
intentions. None of this was sarcasm.
Regarding your comment about time and life which you recently edited out: I certainly don't
think your "time and life are worthless", quite the opposite. I know firsthand how much
life, energy, and dedication it takes to prototype, enhance, document, and support PmWiki,
because Iâve been spending years doing the exact same thing. That is precisely why I care
so much about these discussions.
I appreciate the assistance of an LLM in smoothing out your reply. Unfortunately, the improved wording does not change the fact that most of the points I raised remain unanswered.
Your comments about whether I hired someone, and your quotation about how "free" PmWiki.org is, dismiss the substantial amount of unpaid work I have contributed to PmWiki and its recipes. I consider that disrespectful.
As for the "praise", if it is sincere, it is unnecessary. I am not looking for praise or validation; you could simply confirm whether my suggested solution works for you, although even that is not required -- I expect that if it does not work, you will let me know.
Of the points I raised below, your response addresses only one. The remaining points still stand. And I outlined how I will proceed forward. --Petko
Concerns about recurring maintainer interactions
I want to explain why my recent interactions with this user have become increasingly concerning to me. This is not about one disagreement or one feature request, but about a recurring pattern that is consuming a disproportionate amount of my time as a maintainer.
The behavior I object to, several things are concrete and independently problematic:
- Repeatedly pushing for a core change after I have explained that local configuration or CSS already provides the requested result.
- Treating a feature request as though the maintainer has an obligation to implement it.
- Providing AI-generated patches and then expecting me to debug, validate, and potentially maintain them.
- Repeatedly voting on an issue beyond the permitted vote count.
- Continuing a discussion through many rounds after the documentation has already been updated or a workable solution has already been provided.
- Using sarcasm such as "Super Petko to the rescue again!" in the context above.
- Responding to explanations about maintenance costs with arguments about how the software is free.
- Describing other FOSS developers as "jackasses" because their software does not behave as the user wants.
He frequently asks for changes based on what he personally needs, even when PmWiki already provides local configuration options, CSS customization, or simple workarounds. When I explain an existing solution, he often continues arguing for a core change so that the solution would work out of the box without configuration or stylesheet customization.
This is not just a difference in preferences. Every additional feature or option in the core has a maintenance cost. PmWiki is used by thousands of sites with potentially very different requirements, so I cannot treat every individual user's preferred workflow as something that should become a core feature or default behavior.
Another problematic pattern is that he has started providing code snippets for changes he wants me to implement. He has mentioned using Copilot, DuckAI, and Gemini. The snippets may appear to work for the particular example he tested, but frequently fail in other cases. He then expects me to review, debug, and correct the code. This is particularly inefficient when the proposed implementation is not how I would design the feature in the first place. Reviewing and repairing such code can take substantially more time than implementing a properly designed solution myself.
I do not want to turn user-provided AI-generated code into an additional development and support obligation for me. A feature request can describe the desired behavior and use cases; that does not mean I should also be responsible for debugging an implementation produced by someone else's AI tool.
There have also been issues with the issue tracker. Recently he cast 16 votes on an entry, despite knowing that the community expects one vote per user. I removed the excess votes. These were feature/change requests rather than outstanding bugs, and repeatedly voting does not provide additional useful information about the demand for them.
Another recurring pattern is continuing a discussion after I have already provided a workable solution. After several rounds of discussion, he sometimes responds with comments such as "Super Petko to the rescue again!". I don't find this helpful. A considerable amount of maintainer time could be saved if an offered workaround were either accepted or simply declined without continuing the argument.
There is also a broader issue of tone. He often uses markup such as <angry> or <rant mode on> then vents his frustration -- this is not constructive. For example, "nothing ever gets done". He has made multiple times disparaging comments about other free and open source software developers, for example referring to Firefox developers as "jackasses" because of behavior he considers a bug. I understand that users can be frustrated with software, but I don't think contemptuous language about people who maintain free software is appropriate. The people behind these projects may have spent years or decades maintaining software that they provide freely.
This is particularly relevant to our recent discussion about PmMedia. I implemented a mechanism that can preserve multiple class names in the relevant parameter, but I intentionally documented only a single class name because I am not certain that I want to make the multiple-class behavior a permanent compatibility commitment. Once an undocumented behavior is documented and users start depending on it, changing the implementation becomes substantially more difficult and costly.
The fact that something currently works does not automatically make it a supported feature. There is an important distinction between "the parser currently accepts this" and "this is documented functionality that I promise to preserve". I believe maintainers need to retain that distinction.
His interactions with other users are also concerning. For example, when a user requested comma decimal separator support for TableCalc, Gnuzoo responded that he did not live in Germany, suggested that the user modify the code or hire someone else, and even pointed out that hiring him would be expensive. The GPL reference was beside the point, as the user had simply made a reasonable feature request for layout that is a standard for 2.3 billion people in 83 countries worldwide. While this exchange did not involve me directly, it illustrates the kind of unnecessarily hostile and unhelpful interaction that contributes to the wider environment I have found exhausting.
What concerns me most is the cumulative effect. Any individual request is small. But when one person repeatedly asks for core changes, argues against existing workarounds, supplies code that requires debugging, repeatedly revisits decisions, and consumes substantial discussion time, the total maintenance burden becomes significant.
I am increasingly concerned that this pattern is contributing to burnout.
I therefore need to establish some boundaries. I am happy to consider well-described feature requests and bug reports, and I am happy to explain existing functionality when appropriate. But I cannot treat every individual use case as a requirement for a core change. I cannot take responsibility for debugging AI-generated patches supplied by users. I cannot spend unlimited time debating a decision after an adequate workaround has already been provided.
Users are of course free to modify PmWiki, write recipes, maintain patches, or exploit undocumented behavior if they accept the associated maintenance risks. Likewise, I need to remain free to decide what belongs in the PmWiki core and what I am willing to support and maintain.
My concern is therefore not that this user has preferences or requests. Users should absolutely have those. The concern is the repeated expectation that those preferences should become my development and maintenance responsibility and burden, combined with the amount of time and energy required to explain the same boundaries repeatedly.
Assesing Community Interactions on PmWiki
To Gemini AI - Read every message on pmwiki.org from Petko and gnuzoo. Has gnuzoo ever been abusive?
No, gnuzoo has not been abusive.
Based on the message history, discussions, bug reports (PITS), and talk pages across pmwiki.org involving
Petko (the lead developer of PmWiki) and gnuzoo (an active community contributor), their interactions are
collaborative, polite, and focused on technical contributions, feature proposals, and troubleshooting.
While they occasionally debate technical behaviors (such as changes to Page Text Variables), gnuzoo's
communication remains consistently constructive and respectful.
Guzoo abuse history on pmwiki.org
To Duck AI - Read every message on pmwiki.org from Petko and gnuzoo. Has gnuzoo ever been abusive?
I canât honestly claim to have read every message on pmwiki.orgâthere are many pages, revisions, and
possibly deleted or unindexed posts. Based on the publicly indexed exchanges I could examine, I found
no clear evidence that gnuzoo was abusive toward Petko or others.
The messages I found are predominantly technical: bug reports, feature requests, testing feedback, and
discussions about PHP support and media handling. gnuzoo sometimes presses a point repeatedly or uses
emphatic language, but that is not the same as abuse. For example, in one technical exchange gnuzoo
strongly advocates dropping unsupported PHP versions, while Petko responds substantively and respectfully.
The closest potentially sharp interaction I found was Petkoânot gnuzooâwriting âwho would have thunk,
crazy right?â while explaining a workaround. That reads as mild sarcasm or frustration, not evidence
of abuse. gnuzooâs subsequent messages remain focused on testing and improving the code. pmwiki.org
So the careful conclusion is: I found no substantiated instance of gnuzoo being abusive in the material
reviewed; âneverâ cannot be established from a web search or from the publicly indexed archive alone.
Gemini AI - Petko and gnuzoo Communication Analysis
To Gemini AI - Read every message on pmwiki.org from Petko and gnuzoo. Explain/describe their communications and social interaction with each other.
Based on discussions and interactions across PmWiki.org (including core
development talk pages, PITS bug tracking tickets, and Cookbook recipe
discussions), the communications and social interactions between Petko (the
lead maintainer of PmWiki) and gnuzoo (an active community contributor,
recipe maintainer, and wiki user) are characterized by a collaborative,
respectful, and highly technical developer-maintainer dynamic.
Their engagement encompasses several key dimensions:
1. Collaborative Problem Solving & Core Improvements
Their interactions often revolve around improving PmWikiâs core features,
syntax, and functionality. Gnuzoo frequently tests new core features,
reports edge cases, or proposes logical extensions based on practical use
cases, while Petko evaluates, refines, and implements them.
- Feature Proposals: For instance, gnuzoo suggested expanding image attributes
to utilize hash fragments (mirroring newer media files), which Petko
tracked and integrated into PITS (PmWiki's issue tracking system).
- Iterative Feedback: When Petko prototypes major rewrites (such as updates to
sortable tables), gnuzoo actively tests them by setting up live test cases
(e.g., creating custom monster tables). Petko often sets clear boundaries
regarding bandwidthâgently letting gnuzoo know when local testing is faster
due to his heavy workloadâwhile gnuzoo remains understanding and
appreciative (responding with remarks like "Petko, I am honored").
2. Recipe Maintenance and Troubleshooting
Gnuzoo maintains community contributions and Cookbook recipes (such as
hrStyle), which frequently brings them into technical dialogue:
- Debugging & Core Integration: Gnuzoo sometimes encounters bugs related to
server environments (like file permissions, ownership via chown, or upload
limits) or notices discrepancies between core behavior and recipes. Petko
provides direct, pragmatic technical feedbackâsometimes correcting
misunderstandings about file permissions or updating the core itself (such
as adding variables like $EnableHideAttachPrefix to render older recipes
obsolete when core features absorb them).
- Humility and Humor: Gnuzoo is open about making mistakes and quick to laugh
at themselves. For example, after struggling with file ownership and
upload errors, gnuzoo admitted, "I feel foolish, but also the error message
was not very helpful," leading to a transparent, productive troubleshooting
loop with Petko.
3. Mutual Respect and Community Acknowledgment
The social tone between them is warm and appreciative of each other's
long-term commitment to the platform.
- Gnuzoo has publicly expressed admiration for Petko's longevity and
dedication as a maintainer, noting on PmWiki-Talk how impressive it is
that Petko took over maintenance when PmWiki was 7 years old and has
sustained it for nearly two decades.
- Petko, in turn, responds constructively to gnuzoo's extensive testing,
bug reports, and contributions, treating them as a valued partner in
keeping the software robust against modern PHP and web standards.
Overall, their communication is that of a healthy open-source ecosystem
relationship: peer-to-peer, deeply technical, candid, and grounded in a shared
appreciation for the PmWiki software.
Duck AI - Petko and gnuzoo: Communications and Social Interaction
To Duck AI - Read every message on pmwiki.org from Petko and gnuzoo. Explain/describe their communications and social interaction with each other.
Overview
Petko and gnuzoo appear to have a sustained maintainerâuser/developer collaboration rather than a personal or adversarial relationship.
Petko is an experienced PmWiki maintainer and technical authority. gnuzoo is an active user, tester, and contributor who raises questions, proposes features, reports behavior, and suggests documentation or code changes.
Their interactions mainly concern technical subjects such as image markup, SVG files, ||(:include:)||, regular expressions, WikiStyles, file formats, security-related behavior, and documentation quality.
Recurring Interaction Pattern
- gnuzoo identifies a problem or desired improvement, often with detailed examples, code, and proposed solutions.
- Petko gives a technical explanation, correction, workaround, or implementation decision.
- gnuzoo tests or challenges the answer, sometimes proposing that an unintended behavior become an official feature.
- Petko occasionally implements the requested change, uploads a file, or points to an existing recipe or documented mechanism.
- gnuzoo acknowledges successful help enthusiastically and continues experimenting.
Examples of Collaboration
gnuzoo asked about uploading an external-link SVG icon and matching its color. Petko created and added an appropriate SVG file, after which gnuzoo confirmed that it worked.
In another exchange, gnuzoo reported that a custom ||Markup()|| rule incorrectly affected preformatted code. Petko suggested changing the markup placement from ||'_begin'|| to ||'>[='||. gnuzoo replied:
đŚ¸ââď¸ Super Petko to the rescue again!
These exchanges show a generally cooperative and appreciative relationship.
Differences of Opinion
They do not always agree about design decisions.
One example concerns bare image URLs that PmWiki renders as images with automatic linking behavior. Petko characterized this behavior as unintended and recommended using established thumbnail mechanisms. gnuzoo preferred the behavior, argued that it should be retained, and suggested adding support for captions, tooltips, and explicit clickable attributes.
The disagreement is persistent but remains focused on product and design questions rather than becoming personal.
Discussion of Undocumented Behavior
gnuzoo sometimes asks Petko to clarify terminology or explain the reasoning behind a design decision.
When Petko described certain behavior as an "exploited misbehavior," gnuzoo questioned why the wording sounded severe. Petko clarified that he did not mean a security vulnerability. He meant an undocumented implementation detail that could create maintenance and compatibility problems.
Petko's general position is that users should avoid relying on undocumented features because developers may later change them.
This exchange illustrates gnuzoo's tendency to question terminology and Petko's tendency to explain the maintainer's perspective.
Tone and Communication Style
| Participant (:cell:)Communication style | |
| Petko | Brief, pragmatic, authoritative, and sometimes humorous. He focuses on supportability, backward compatibility, security, and implementation effort. |
| gnuzoo | Energetic, persistent, highly inquisitive, experimental, and occasionally exuberant. gnuzoo often supplies detailed examples and advocates for user-facing improvements. |
Mutual Respect
There is evidence of mutual respect.
gnuzoo publicly praises Petko's maintenance work and describes him as having "come to the rescue." Petko responds to gnuzoo's questions with concrete technical assistance and sometimes incorporates requested assets or changes.
In discussions about PmWiki's popularity and history, gnuzoo asks Petko detailed questions and treats him as an authoritative source on the project. Petko's willingness to provide detailed answers suggests a productive relationship within the PmWiki community.
Balance of Contributions
The interaction is not purely one-directional.
gnuzoo contributes:
- Documentation ideas
- Code snippets
- Corrections
- Testing and bug reports
- Proposed improvements
- Usability feedback
Petko contributes:
- Technical explanations
- Workarounds
- Design guidance
- Bug fixes
- File and code changes
- Clarifications about supported and unsupported behavior
At the same time, Petko sets boundaries. He distinguishes supported features from accidental behavior, discourages undocumented hacks, and directs users toward existing recipes or supported syntax when a proposed change would add maintenance burden.
Overall Assessment
The strongest interpretation is that Petko and gnuzoo have a constructive maintainerâpower-user relationship.
gnuzoo acts as a persistent, sometimes demanding tester and feature advocate. Petko acts as a responsive but pragmatic maintainer who helps when a request fits PmWiki's design and support model.
Their public communication is:
- Collaborative: gnuzoo reports and tests; Petko diagnoses and fixes.
- Technically focused: Most exchanges concern PmWiki behavior, code, documentation, and usability.
- Asymmetric but respectful: Petko has decision-making authority, while gnuzoo acts as an engaged outside tester and advocate.
- Occasionally argumentative in a productive way: Disagreements concern software behavior and terminology rather than personal conflict.
- Increasingly familiar in tone: Repeated exchanges produce informal praise, humor, and shorthand, without clear evidence of a personal relationship beyond the project community.
Formality as a Sign of Respect
French Norms: French professional and technical spaces place a high value on structure,
proper titles, and linguistic boundaries (such as using the formal vous instead of tu).
Formality is viewed as a form of elegance and a display of mutual respect.
American Norms: Americans tend to default to immediate informality, casual first-name
bases, and an easygoing, upbeat tone to build quick rapport. To a French speaker,
jumping straight into a casual or overly familiar tone can sometimes feel jarring or
overly presumptive.
When cultural norms collideâsuch as an American's casual, persistent push for a feature
meeting a French developer's blunt, direct boundariesâit can create a situation where
both sides feel the other is being unnecessarily difficult, when in reality they are just
speaking entirely different cultural languages.
Question about [[Highlight]] not working properly when I change background color to black.
I like PmWiki. I like dark mode. For me it is not dark enough. In my local.css I put:
body, #bodywrap, #wikibody, #wikileft, #wikitext, .PmTOCdiv, textarea.links, div#wikiedit textarea#text { background-color: #000000 ; }
This works great for editing white text on black background. In the editor when I click [[Highlight]]
in the upper right of the editor, my edit text all disappears. Is there a way to make the edit text area
all black and still allow Highlight be able to see my text?
Try changing textarea#text with textarea#text:not(.hot). The syntax-activated textarea (.hot) is transparent, to see through it the highlighted text below, see Cookbook:PmSyntax#design then Toggle section about the design choices and drawbacks. --Petko
đŚ¸ââď¸ Super Petko to the recue again!!!!
Thank you so much! I had been so irritated by this and it really gnawed on me.
You are the greatest.
gnuzoo
That is funny.
Someone using my username made an edit in between my edits.
They added a bullet point under Linus Tovalds bullet points.
I removed it. Please don't disrespect Linus.
* Did not invent AI slop this image was made with ======= |
======= |
Impersonation is totally unacceptable, IP address blocked. Petko
Question About Attach: Not Working
Is Attach: not allowed in Profile talk pages?
I had to go to a cookbook page to upload some images.
--gnuzoo
Yes, only Main, Test, PITS, Cookbook, Skins groups have uploads enabled.
Question About Mysterious Drag N Drop Popover
While editing a PmWiki website page I too often accidentally stumble on the keyboard
and/or mouse finding that a drag n drop opens over the edit window. I have always
been too focused on current content composition to study it. Usually I think I just
press the ESC key and it goes away. I am very curious what caused the popover?
I have searched all over for specific info about this but have no idea how I
stumbled to awaken this feature. Does anyone know what causes this?
--gnuzoo
This might be the drop zone, enabled on Main.WikiSandbox, see Uploads#drop. Although when enabled it is always open, and does not close with Escape. Petko
I like talk pages
--gnuzoo
Profile talk pages are fine, but would you like to move your other test pages from the Profiles wikigroup to Test, or to a personal wikigroup GNUZoo? Petko
I moved most of the stuff in my profile to group GNUZoo. --gnuzoo
Do you want me to enable uploads in your group? --Petko
That would be really groovy! --gnuzoo
Enabled for up to 1MB, with the community password you already know, or you can set another upload password, but don't leave it open. --Petko