archive_me1Add my vote for this tag create new tag
, view all tags

Feature Proposal: Change plugin ContactAuthorFirst policy to NotifyAuthor


TWiki is an open source project. TWiki as well as plugins are covered by good old GPL license.

I find it right out silly that a plugin author can define his plugin as ContactAuthorFirst.

Description and Documentation

It is already the policy that if you contact the plugin author and he does not respond you edit the plugins anyway. And I have seen the regular developers change other peoples plugins many times. Typically to fix them when they no longer work with a newer TWiki version. So in reality we regulars do not respect the ContactAuthorFirst anyway.

Let us accept what open source collaboration is all about and change the policy to NotifyAuthor. This would mean that if you want to change another authors plugin and this policy is set, you go ahead and modify the plugin but also pop the original author an email telling him what you are doing. If he disagrees then he can always start a discussion which most likely ends with an agreement or revert the changes. But in 99% of the cases the changes to a plugin are bug fixes that I am sure also the original author is happy to get also.

And in the rare case two developers cannot agree, the new developer can simply copy the plugin and make a new with enhanced or changed features.

I am writing this proposal because I am seeing more and more plugins with the ContactAuthorFirst where the documentation could need improvement, or where bugs are being fixed with patches in the Dev topic but the original author never picks them up. I am sure the NotifyAuthor policy would make more casual developers upload a fixed version of a plugin or check fixes into SVN instead of just putting yet another patch on a Dev topic just to be ignored.


WhatDoesItAffect: Plugins


Announcement and update of the Plugins form. I am willing to do that.

-- Contributors: KennethLavrsen - 25 Oct 2007


ContactAuthorFirst is standard for the Linux kernel. Linus called himself "a cvs with taste" ... those days they still used cvs.

Anybody changing someone else's code should contact him first just for the good of collaboration. Saying nothing and just tinker with it is not very friendly, so to say. All too often it is perceived hostile without any preliminary communication.

So I am voting "No" to your proposal. Maybe I should raise a DefaultToContactAuthorFirstPolicy propsal wink .

True, many plugins are abandoned and still marked as ContactAuthorFirst. Part of find out that it is abandoned is to first contact the author. If it is abandoned, you either get no response or something like "oh I don't use twiki anymore. just go ahead and do with the code what you want. don't forget to add yourself to the authors' list" ... which is just want you wanted to hear, probably. You fullfilled the plugin policy. It does not say WaitTilTheEndOfNowhereTilTheAuthorReacts.

A ContactAuthorFirst way of collaboration is so much part of collaboration that it isn't even mentioned in the GPL wink , putting aside that ContactAuthorFirst is an ethical aspect and GPL covers legal aspect only. As such it talks about that you are allowed to take the code and fork it, e.g. if collaboration on a common goal does not work out anymore, either for technical reasons or due to personal differences, or if the code has been abandoned.

-- MichaelDaum - 26 Oct 2007

I was bitten by this once, even though it was just updating docs (TimelinePluginDev). In general it is clear that plugin authors write plugins for different reasons and care about them for different timespans. ContactAuthorFirst currently suggests that a month is a reasonable time to wait when you have changes you want to submit.

I think a way to have more contributions show up, could be to allow for the impatient to start an OpenPluginName fork earlier if a plugin appears stale or blocking. With the best of luck and a little help from the community and the permissioning author the "open" versions of the plugins could be "branched in" again from time to time.

As I see it it is important that we allow new contributors to work as freely as practically possible - the maintenance overhead involved in having "open" versions of some plugins appears reasonable to me.

-- SteffenPoulsen - 26 Oct 2007

A fork should be used as a very very last resort. Most of the time it is a bad thing. That's why we actually see so few forks all over foss-land. If the author does not react for a month or so, why not grab the code as is, change it and release a new version.

  • Personally I have no problem with a timespan of a month. I was thinking of alternatives for the people that do. -- SteffenPoulsen - 27 Oct 2007

-- MichaelDaum - 27 Oct 2007

As Michael says, ContactAuthorFirst is just a question of politeness. I can't actually stop anyone changing one of my extensions (and I wouldn't want to) but I have seen the situation in the past where someone submits a patch for work which I have already done, but not released. If they had contacted me first, I could have told them. Another reason for wanting a contact is the one that Kenneth describes. I don't visit plugin topics all that often, and anyone throwing patches over the wall is likely to be disappointed if they don't contact me to get their patch integrated - especially if they don't update the unit tests.

What makes far more sense to me is to document how changes need to get made. For a plugin in subversion, the right approach is to raise a bug in d.t.o. This serves a dual purpose; it contacts the author, and it documents the change. The problem is that Plugins web is stills stuck in the TWiki dark ages - it has never caught up with bugs web. Or even with Subversion, in many cases frown

-- CrawfordCurrie - 27 Oct 2007

Damn right, Crawford.

Just go and look for these YetAnotherXXXPlugins. I don't want to see that kind of thing happen again.

I have repeatedly tried to make people raise a bug instead of posting to the Dev topic. I made a bold red warning at the top of it not to report bugs on the Dev topic. Dev topics are no good for any sort of issue tracking. Even contacting the author via email is better than that sort of usecase of a wiki.

That leads to a real different issue on how to use these Dev topics reasonably ... and how to head people in using Dev topics the right way ... whatever that is.

I could imagine to have rss feeds for each plugin's bugs in the tracker and display that using the HeadlinesPlugin in the Dev topic, and a big red button "New bug" that links back to the bucktracker. This would at least give us some soft of integration of these two systems. Not sure if people will use that appropriately.

Worse another proposal.

-- MichaelDaum - 27 Oct 2007

Contact author first very clearly implies - "beg for permission from author first".

In reality there is a small hard core developer team - many of them consultants - that normal occational contributors would never dare challenging. And I sometimes think that good small but important contributions are rejected or ignored because people will not pay to have them added. And unit tests are often used as a practical blocking mechanism. It is simple to write a small improvement to an extension. It is very very hard to write a unit test case. So a requirement to provide finished working unit test cases becomes a protection method to avoid contributions to extensions. Or the developer will say "I will look at it when I have time or if you pay me". Why should they pay anything when they have working code that the rest of us can take advantage of. If a casual developer has made an improvement to a plugin, why not let him fix it?

Unit tests cases have been added to TWiki in great numbers. And the quality has fallen during the same period. 4.2 is now delayed by 6 months. In my view because the few hours people have available are wasted on a too difficult unit test setup which only few understands instead of testing the code in a real environment in a real browser. In theory unit tests should be good. But reality is that the quality is lower than ever and fewer contributors participates in the development. And I am sure the unit test hell is one of the main factors of what scares people away. I have almost stopped trying to code anything in core because I spend 10 times more time tying to understand the dammed unit tests than I do on the code. Only in people's own extensions do we see new developers because there noone can bully you.

But OK. If that is how you want it - I am not impressed or afraid of any hard core developers! I will just create a FreeXXX version of an extension if I see too many contributions being ignored and make it "Feel Free to Modify" and "Don't worry about unit tests".

I pull back my proposal and start making OpenXXX plugins.

-- KennethLavrsen - 26 Nov 2007

Why would you dismiss unit tests just because we have still bugs? There could be lots of reasons. Quality is not low because we have unit tests.

I don't think there is anything wrong with the contact policy. You can ask authors that are using ContactFirst to open up if you desired more openness overall.

-- ArthurClemens - 26 Nov 2007

I dismiss units tests the way it is done on the TWiki project because

  • I continuously find new bugs injected it takes 5 minutes to find with a normal browser. That tells me that time is spent on unit test coding instead of testing
    • and if we didn't have the unit tests, you would be finding many many more. While you seem not to acknowledge it, TWiki now has much less scope for bugs to creep in, and due to the unit tests, we have much more knowledge of the corner cases.
  • The broken unit tests are in 99% of the cases a problem with the test and not the code change
    • if a unit test fails, irrespective of the goodness of the code fix, it is still the code that is in error. - the Unit test is both a specification, and documentation for how the product is epxected to perform
  • The unit tests are so difficult to write that a guy like me is no longer able to contribute with small code fixes. I do not believe I am the only one in this situation
    • yes, it is much harder to make small simple seeming changes that break a corner case for someone else (without ever finding the manual test that triggers it)
  • The number of active contributors is record low. Why did they leave?
    • I would suggest that you look at the changelogs of the Cairo release. At that time the number of contributors was much much lower. I feel you are misleading youself, and making false arguments.
  • And finally writing plugins and enhancing plugins is actually not that difficult because we have a good API and examples to follow. The minute you demand people write unit tests for plugins the task becomes 10-100 times more difficult because you now also have to understand how the mainly undocumented unit test framework work (there is ONE topic as documentation) and often also have to understand how the internals of TWiki works in order to write the code that runs the unit tests. It alienates potential new contributors and leave contributions to a small elite. That is bad for an open source project.
    • I'm unsure how the demand that there be unit tests for the TWiki Core impacts on non-core plugins.

I am concerned at some of the plugins and the number of ignored contributions pilling up in the Dev topics. One thing is people begging for features and reporting bugs. But when people upload their own version or a patch and get dismissed then we have a problem.

This is why I would prefer if the ContactAuthorFirst policy would become a NotifyAuthor policy. This still means that people must notify the author so the author can warn if the contributor is about to do something bad without knowing. But demanding that you wait a month is the same as saying "PayAuthorOrGoAway". And the unit tests is one of the excuses used to keep people away.

  • Again, I think you are misrepresenting the truth here. The reality is, that I amd going to work on what I am interested in working on. If someone wants something that is low on my priority / interest list, the TWikiConsulants are providing with a new option to get an idea implemented - one that otherwise does not exist. Payment can either be demonised in the way you are, probably resulting in less work being done on TWiki.org, or used as a tool to acheive more.

And on top of all this we see the elite team constantly updating other peoples plugins without asking or notifying so those that knows how things work know that you can in practical ignore the policy and get away with it.

  • Yes, this also concerns me.

But the ContactAuthorFirst signal we have now says - don't touch this and that is bad.

So I will create Free versions where I see it needed and see what happens.

I know that I am stirring up thing here and probably making some upset. But it is about time someone says the things many are thinking but dare not say out loud. And sometimes it takes some provocation to get people to think about the consequences of the behavior towards newcomers.

-- KennethLavrsen - 26 Nov 2007

From the point of view of one of those nasty contributors that is spending every waking moment working on twiki - and thus is depending on people and companies to pay me so I can eat:

We have had many cases of contributions being thrown over the wall, without sufficient testing, and indeed with insufficient development work to make them reliably workable. The sad fact is, anyone that picks up one of these contributions is then forced to tidy up, create docco, create tests, re-write it, and then some - making it a pretty soul-less task. I made the mistake of integrating a heck of a lot of these sorts of things into Cairo, and got very burnt out with all the work I had to do - and I note that looking at TWikiHeart, that when people do work like that, they don't get recognised for it.

So I don't know why Kenneth imples that those that are contributing the coding work for TWiki, and are working incredibly hard to do so, somehow owe others such a massive free ride.

If you want me to want a feature, its pretty much in your court to make me want it.

Another thing you seem to totally miss the point with, is that its a heck of a lot easier to write unit tests, than to fix the code a year later, without having any idea what the original author was thinking. In fact, While you are complaining about unit tests being hard, I think you're totally missing the point. If a Developer is to lazy to write unit tests, then it often turns out that their code also wasn't written generically enough to simply merge into the core, resulting in a pretty hefty workload for the poor merger.

If a unit test fails, irrespective of the goodness of the code fix, it is still the code that is in error. - the Unit test is both a specification, and documentation for how the product is epxected to perform

But hey, I write code, do you want me to stop?

-- SvenDowideit - 26 Nov 2007

Remember that the original proposal was to change the ContactAuthorFirst to NotifyAuthor.

Remember that what triggered my proposal was the many contributions in plugin Dev topics that are ignorred. This is a fact. Just surf around on the Dev topics.

The unit test part of the discussion is that contributions in many cases are dismissed because they do not include unit tests.

In the core code and default plugins (which are quite advanced) the unit tests have become part of the spec - yes. And I am not suggesting that we stop using unit tests in core and default plugins. And default plugins almost all have FeelFreeToModify policy by the way!!! And they all should have that policy because any core developer is fixing the core plugins all the time. The core and default plugin related unit tests are maintained by many and run daily. And the people that maintain them are familiar with the unit test frame work and help each other making/fixing them

The problem is the normal non default plugins where I find it a pity that one developer can block contributions and use unit tests as an excuse. I still believe that a plugin can be perfectly well tested without unit tests. Plugin contributors are typically not regular contributors and are not familiar with the unit test framework or the internals of TWiki.

The original idea was that it should be easy to write plugins for TWiki. A well specified and stable API and good examples. Even I have written some pretty nice plugins for very specific purposes. But the minute you add a requirement to write unit tests for them using our unit test framework then it goes from relatively easy to very very difficult. And then we loose a lot of contributors. It may be difficult to understand for those of you to whom writing unit tests has become a piece of cake.

The quality issue I mention above is most likely related to the fact that people do not get more time to develop TWiki. So when a developer spends 3 hours on a feature and spends 1 hour coding it and at least 1 hour writing the unit tests then there is little time left testing the feature in many different browsers and many different combinations of configurations of TWiki. Unit tests only find the very low level bugs and hardly ever find bugs related to browsers or feature interactions or incompatibilty with configurations of TWiki.

But again, the scope of this discussion is not the core code and not the default plugins. The objective was to enable those that upload contributions as attachments on Dev topics to more freely release real new versions of plugins without being blocked by the original author for whatever reasons. If someone wants to destroy a plugin community pressure normally handles things and a bad contribution can be reverted easily.

I also think people spend more time testing and documenting a contribution made as a real release. Uploading a zip on the Dev topic usually leads nowhere unless the original author picks them up and people have often not tested them as much as they would have if they has made a release on the real plugin topic through SVN.

But again the proposal is pulled back and I will not create 200 free plugin versions. But when I see a plugin where contributions are dismissed because of lack of unit tests then I will assist the contributor in making a Free or YetAnother or whatever name version of it. And then people can ignore it if they don't like it. No animals will be harmed in the process.

-- KennethLavrsen - 27 Nov 2007

Thanks for rejecting this proposal. Now, let me find some simple words:

Bad behaviour is:

  1. abandoning plugins
  2. not listening to your userbase
  3. ignoring or even rejecting bug fixes
  4. ignoring or even rejecting good contributions
  5. not contacting the author if you have a bug fix or improvement
  6. not answering to a patch that you received
  7. writing bad non-informative bug reports with no way to reproduce them
  8. not providing a better bug fix once the first one has been rejected
  9. rejecting bug fixes or improvements for no good reason
  10. forking an actively maintained plugin
  11. releasing insecure code
  12. creating a FreeXXX or OpenXXX plugin; this is pure FUD because the original plugin was already open
  13. releasing someone else's plugin without contacting him first, not letting the original author intercept this act, thus putting users that do use this plugin for everyday work and try to upgrade at a risk.

Good behaviour is:

  1. accept responsibility for the code you once contributed
  2. take over responsibility for code that has been abandoned
  3. take care that nobody messes up our code
  4. try to collaborate with the original authors
  5. accept additional features "with taste"
  6. comment on added features and give people a chance to come back with an improved patch
  7. be thankful for any bug that someone reports
  8. be even more thankful for any bug that someone fixes
  9. have deep respect for people opening up a can of worms
  10. be able to communicate about bugs and code and whatever
  11. be open-minded and able to accept that you were wrong in your bugreport and a short RTFM answer
  12. be able to accept that the code or patch you provided is indeeed totally crap
  13. be able to say one of the following sentences occasionally:
    1. Oh, I see now.
    2. I was wrong.
    3. You are right.
    4. I don't know.
    5. Can't we do both.
    6. Shit, where was I when I wrote this code.
    7. Wow, what a great idea.
  14. accept that the original author is the official authority for his/her code
  15. be eager and willing to learn, either by yourself or by listening to more experienced people
  16. be able to put aside your own ego and still remain authentic
  17. take everything with a dash of humor
  18. have a certain acceptance for people not behaving good
  19. take care that the project is not put at risk by bad behaviour or accepting too much of bad behaviour

I may have missed some important points. But most of us may agree on this so far.

Now let's add the human factor:

  1. plugin authors do abandon plugins and even TWiki for whatever reason (maybe, there are more important things in the world than TWiki)
  2. plugin authors make faults
  3. bug fixers and feature contributors make faults
  4. most bug fixes can't be applied as is; they have to be supervised by more experienced coders, e.g. the original authors
  5. tracking bugs and improvements is a very very hard job, that you can easily fail.
  6. remember that whenever someone comes to you with a bug fix then this is because there was an error; they don't come to you when there is no error and everything is fine. As a sideeffect they come to you with a certain amount of anger, that the maintainer has to compensate.
  7. everybody who has code released in the open, is in danger of losing his reputation. that's additional pressure, besides getting the thing fixed.

Let me close by addressing some words to Kenneth directly:

  1. don't encourage forking code, please.
  2. encourage collaboration and productivity instead.
  3. take a stress pill wink

-- MichaelDaum - 27 Nov 2007

smile Nothing to add here.

-- FranzJosefGigler - 27 Nov 2007

Good input Michael. Honestly. I am happy with it.

And if all plugin authors follow Michaels good advice you will never see a fork made my me - or by anyone else. Noone really wants to fork.

It seems very much in line with my original proposal (but without the name change). So if Michael's behaviors become common practice then we will see more contributors that are allowed to make plugin releases of plugins even though the policy is ContactAuthorFirst. After all it is not a OriginalAuthorOnly policy we have today.

Michael any good stress pills you can recommend? wink

-- KennethLavrsen - 27 Nov 2007

Oh I can spare some.

-- MichaelDaum - 27 Nov 2007

Topic attachments
I Attachment History Action Size Date Who Comment
Waveform sound filewav stress.wav r1 manage 116.7 K 2007-11-27 - 16:22 UnknownUser Kubrick rulez
JPEGjpg stresspills.jpg r1 manage 6.0 K 2007-11-27 - 16:39 UnknownUser  
Edit | Attach | Watch | Print version | History: r19 < r18 < r17 < r16 < r15 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r19 - 2008-09-17 - MichaelDaum
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2018 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.