> Andreas pointed this out on twitter:
>
>
http://pypi.python.org/pypi/collective.plone3bugfixes/0.9>
> It's a bit sad to see people do this. It'd be good to get these into
> Plone proper.
>
> It'd also be nice if the people behind that product could fill in a
> contributor agreement and just make the fixes in Plone svn. I understand
> that it can be frustrating to wait for people to have time to action
> your own bug reports, but *surely* it'd have been less work to fix this
> in Plone than to release a product like this.
I'm going to stick my neck out here and opine that, in fact, sometimes it
just *is* easier to create a product like this. I understand completely
the frustrations that may have led the authors to create and release this
product.
I'd like to sketch out a few 'user' scenarios:
1) Total Plone neophyte, just knows how to install and use it; they find a
bug. They don't know what to do, so they leave it and hope that the next
Plone version fixes it. I bet a lot of people fall into this category
2) Almost Plone neophyte, has installed Plone, figured out how to google
when they run in to trouble, and, amazingly, are motivated enough to sign
up for an account and submit a semi-sensible ticket into the bug tracker.
They have no idea how to fix things, but are able to describe a problem
OK. I bet there are not all that many people in this category. I suspect
mainly people end up here when the pain factor of the bug is high enough
to turn type (1) people into type (2) people.
3) Plone tinkerer, integrator, customiser. This person hits a bug, pokes
around in the guts of Plone's core code, and maybe gets lucky and figures
out just enough to see what is wrong and hack up a fix that Works For
Them. 3a) If the Plone *community* is lucky, these people file a bug
report, include a snippet describing what *they* did to fix the problem
for themselves, and maybe even, if they're really savvy, attach a patch.
Possibly there's more people only in (3) than in (3a).
4) Experienced Plone developer, integrator, etc. These people probably
code in or with Plone and Zope for money, but they either lack the time,
resources, motivation, legal advice, or whatever to fill out the
contributor form and become a core developer. Hopefully most of these
people, when they find a bug, will file a bugreport, and probably, because
they're doing it for money, they will attach a patch. But once again, I'd
say the odds of getting a patch that also updates/creates tests is about
50/50 here - the barrier to entry for understanding and using the many
facets of Plone's test infrastructure is quite high. Hint:
http://plone.org/search?SearchableText=create+test+case5) Plone core dev. 'nuff said.
Personally, most of the time I'm in between (3a) and (4), but the odds of
me ever filling out the contributor agreement are very low, for a variety
of reasons, including both time and the hurdle of getting legal advice. I
have submitted bugreports on their own, submitted bugreports with patches,
and submitted bugreports with patches and tests, but almost universally
these bugreports have languished. Eventually, most of them have been
closed, but I still have some open for a long time, including even ones
that I submitted a patch for (no tests on this one) and then even
*reworked* the patches on (
https://dev.plone.org/plone/ticket/8466).
There are some situations where just releasing a hotfix/monkeypatch
product to fix a pain point is Just Going To Be Easier (and I don't
necessarily think of this as a bad thing). For example, bug
http://dev.plone.org/plone/ticket/5665 - This bug has been open and
relevant for more than *three years*. I have a patch and can hotfix this
relatively trivially, but in order to fix it 'properly', not only do I
have to supply a patch + tests for some core Zope functionality, but I
then have to supply a patch + tests for some core Plone functionality. Or,
I could just release a hotfix product. *Or* I could just not bother and
simply Fix It For Me. In fact, what I have done is bugreport/feature
request it in Zope + patch (it's languishing - needs tests
https://bugs.launchpad.net/zope2/+bug/193122), and comment on the Plone
bugreport (+ patch!).
The comment on the PyPI page for the plone3bugfixes product says: "The
reason why we don't write bugreports is that nobody seems to care about
them. Yes, we tried before."
I sympathise with that.
If the question is 'how do we turn (3a) and (4) into core contributors?'
then the first suggestion I would offer is simply that the mere existence
of bugreports + patch attempts, no matter how poor, are the signal that
someone is *ready* to *potentially* become a core contributor, and
therefore that these efforts should be *actively sought out* and
*encouraged* so that they will develop further. I took the liberty of
searching for tickets created by one of the authors of the plone3bugfixes
product. It seems he submitted a bugreport/feature request along with a
tentative patch some 18 months ago. It is languishing, because his patch
wasn't a "working patch" so that ball was punted back into his court to
action. I guess if it Worked For Him, then at that point flat-out
rejection was enough to kill that nascent motivation dead.
Anyhow, just my 2c.
regards,
Darryl Dixon
Winterhouse Consulting Ltd
http://www.winterhouseconsulting.com------------------------------------------------------------------------------
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers
