Hi, I'm seeking help, if there is anything one can do, if a member of the collective silently deletes functionality out of an add-on, and stays unresponsive since a long time, when it comes to restoring?
In particular it's about the possibility to send an item's rich-text-body (including links, pics, etc.) via a content-rule:
TIA, Ida
Easiest way is to provide a Pull Request on your own fixing the problem or hire someone to do so.
Be also aware there is a PLIP drafted to bring collective.contentrules.mailtogroup into Plone core. So it is probably a good idea to contact the propose and seconder in the issue.
hth
Allright, maybe this is a misunderstanding: I'm not talking about a bug, but about someone making a commit and with it, deleting existing functionality. Which is unfortune already, but reverting or restoring would be the least to do. At least in most of the teams I've been, so far.
I had already put quite some time and effort in complementing the add-on (thanks to K.C. Leong, btw), to also be able to substitute the parent-title and rich-text-field in email-msgs. Someone rips it out and now I'm suggested to pay for the restauration, or redo it myself. Mmhm, ok, thanks for the answer.
So please don't wonder, if participation still decreases. One cannot silently remove features of an OpenSource-repo and then stay unresponsive about it, IMHO.
Ida, I never used that addon, but if I get it correctly the feature was ripped out because plone.stringinterp was used in order to have some advantages from it. Unfortunate, that it does not support the replacements you need ootb. So (without looking at the code myself), I have the impression that a simple revert is not what pushes the code forward.
But plone.stringinterp is modular so add-ons can register own replacements and there is already one which supports the feature your looking for.
So there might have been communication problems, but this is nothing which is completely difficult to solve. I looks more like the usual 2-3h needed to make it work for you again.
Thus said, and given I am not involved at all in this package, I'd take my energy and make the thing fly again using the excellent tools we have available.
Jens, thank you very much for an explanation! So, rich-text was dropped in favour of implementing plone.stringinterp, because that was not possible to interpolate. I don't fully understand the need for this change, because everything works fine with the older version before the rip-out. And you are absolutely right, it's a communication-problem, because there was no communication about it beforehand, and when I ask what's going on, there's no answer. By far not the only time that this happened to me and part of the reasons, why I often hesitated to get more involved (=to communicate more) for collaborating more.
Which brings up to my mind, that you and especially @davilima6 were super helpful and communicative about a bugfix-PR, a few months ago, that was fun, thanks again 
Have a good evening (night/morning...) everybody, Ida
1 Like
Hi Ida,
i'm sorry for the delay.
I understand that you're upset for a missing functionality that in the previous versions worked.
As Jens said, the focus was to use stringinterp to give more modularity to this product.
As i said in my past comments on github, the fix should be very easy, but unfortunately in the last month i had some problems that doesn't let me more spare time to close this bug..and i didn't have any paying project that needed this product.
I'm afraid about this situation and i will try to fix it as soon as possible, but these are the good and bad things of an open source project.
Good things: we are a wonderful comunity and @jensens wants to help me and you to fix that bug and push this product forward (btw: thanks, but I could try to fix it in next days)
Bad things: if no one pays for a project, we need to fix the bugs in our free time, with this kind of problems.
Hi Andrea, thanks it's very nice of you to claim to fix it as soon as possible, like you wrote on GitHub more than a year ago. You also argued that it's not important, because no one seems to miss it. That's a weird argumentation to me, at least reasons shoud be given before removing functionality of collective-add-ons, or also the core.
One more arbitrarily example amongst many for another rip-off done during the movement towards Plone-5, was the removal of the logical-operator-fields in collections, which gave much more power to the users for defining the search-criteria, than they have now.
At that time, it wasn't communicated in a noticable way that they were about to be removed, it's still not clear to me why, and I wonder if the mindset was also here: Just do it, and see if anyone's missing it.
Well, I can tell you, I know several people who miss them, the interesting question would be, why they don't speak up.
Personally I have not much interest in continuing participating in the collective, because the implication repeatedly is, that people are claiming you to do unpaid work, where instead already done (unpaid) work is ripped out.
Anytime I was reading the "standing on the shoulders of giants"-meme here, I thought to myself it's more like "ruining the shoulders of giants". I had chosen Plone and ZOPE back then also, because it was not one of the fashions flying by, and because changements were much more transparently announced and discussed.
Glad to see PLIPs are back, though. A minimum guarant of transparency for truly opening the source.
-ida
Keep in mind...
- packages change, features are removed/added. It happens
- you can always use older versions
- you can fork and do your own thing
- no one is obligated to fix someone else's problem
- we all have limited time/resources
@cekk was spending time improving the package. It seems like there was no active maintainer. It was nice of him to spend time open sourcing his work and improving the project. Don't make out to be some public witch hunt.
If you were the package maintainer, you could have reverted his PRs. Or if you were frustrated enough, just move it into your own fork somewhere else.
I maintain my own forks for some packages--it's not a big deal. People solve problems in different ways--it happens. I certainly hope you weren't waiting around a year for someone to fix a problem for you and then publicly try to shame the person who didn't do work for you? Can't you just use a previous version if it burns you so bad?
Sorry, kind of the way open source works... 
"Glad to see PLIPs are back" -- when did they ever leave?
3 Likes
About the origin of this thread: I have a fork, it'll get uncompatible once the add-on goes into core and don't worry nothing is burning, but you continue to ignore it's not a bug-fix, it was a silent feature-removal. That's odd, if you see that different, fine.
I am not addressing single persons nor shaming them. I'm trying to point out what Jens already stated: There are communication-problems. And there's a lack of transparency on design-decisions, which affect all Plone-users. Also when I addressed the lack of moderation of an offending post of a known troll, who is suspended in other forums for many years, I was not addressing the troll in person, but the damage it does, if people cannot feel well to speak up, because you might get a "Have you taken your pills?" or the alike, as a reponse.
And another example why I don't feel much engaged to participate, is when the very same question gets very different answers of the same person: One time kind and helpful the other time not, depending on who is asking, it seems. I don't link to it, to not shame further persons as you see it, that's the least thing, I wanted.
It is claimed the Plone-foundation wants to engage people in participating, I'm just trying to point out what can be hindering, if you insist to turn that around, please go on.
Your questions about missing PLIPs is irritating, but I'm stopping it right here, because I prefer to not get weird followers or emails everytime I dare to speak out, anymore.
-ida
@ida btw i never said that this bug/missing feature is not important because no one seems to miss it..obviously it's important because is useful and it was a feature that was silently (unwanted) removed.
I only said that it's easy to fix/restore.
From my point of view, the essence of an open source project is that in some not-core functionality shit could happens. Different people could work on the same product and make bugs. In an perfect world everything is fully tested and is easier to notice if a change breaks an old feature and revert it before releasing something.
But this is not a problem for me, because you could open an issue, talk/comment about problems and eventually fix it an make a pull/request.
If the "bugger" can't help you (for whatever reason), you could ask help on other channels (like this forum) and i bet that you'll find someone that have some time to invest to fix the problem. I think that no one in this community wants to keep some product bugged intentionally.
1 Like
@ida you raise valid issues, and I believe the responses of others here are equally valid.
The problem is that unless someone pays for work or does it themselves, they do need to convince others to do it (unpaid). It's both a problem and a freedom.
I've forked repos to make quick fixes or to revert commits I didn't like.
There is so much transparency in Plone that I can only skim the surface of what's happening (all the work being done) all the time. I don't have time to read all the GitHub notifications or catch PLIPs as they're being proposed or commented on.
Earlier this year I heard of a big company that wanted to use Plone but ran into an LDAP issue, and after talking to others we were able to use a crowdfunding approach to get the missing feature implemented. That's a (new?) now proven approach available to the Plone community. Perhaps we can use your example to make that approach and process more mainstream. We have been talking about a kind of bounty system that might help us assign a kind of stipend (not fully consulting rate paid) to different bugs or features that are clearly blocked. It would be great if you wanted to help us move that concept further.
1 Like
in this particular case I think the pain point was existing functionality being dropped. Thats not easy to solve but perhaps one way to make it less likely is that when you implement a feature, to have tests and documentation that really describe the importance of its usecase. That will make people think twice before dropping the feature.
1 Like
Hey guys, just wanted to thank you for your replies. Yupp, tests are a great way to diminish human-errors, which happen and I was merely saying "can you please restore the deletion" and didn't think it would be such a problem. Thanks given, Plone has an extraordinary motivated tests-automation-team to keep everything smooth and up-to-state. Apparently again, I'm suggested to ask/pay for something: no thanks and don't worry I don't need this, I can use the fork, but maybe others would like to use it too... (repeating myself here).
@tkimnguyen Providing a space for people to come together with the same feature-needs and forming working-groups, sounds like a pretty good idea, thanks for the suggestion. I would like to get back to this, but that might be not within this year. Cheers, Ida