Remove poll module from core

+1

Robin
I ♥ Bugz

Polls are surely something which should be included in Drupal core.

So... you would remove poll.module from core, hack on it for a while, then put it back?

Polls are surely something which should be included in Drupal core.
No, they should not be included in Drupal core.

Drupal core should be more like a framework than like a system that covers all needs.

And this framework is then extended by modules.

However, I think when we start removing stuff from core, we have also to introduce the idea of the 'golden modules', which will be a collection of 'core-like modules'. Modules, which are actively maintained and are considered important.

These modules can then also be gathered together in some kind of drupal distributions.
There is currently a discussion in the development mailing list on that topic, you might want to read this:
http://lists.drupal.org/archives/development/2006-05/msg00029.html

best regards,
frando

-1 for "removing stuff from core". Drupal is not just a framework. Using the same argument you could say that we don't need comment, blog, page, archive and other modules in core and make default installation package unusable.

Besides, I often find additional modules buggy and sometimes incompatible with current version of the core.

Before you get into an argument about "what belongs in core", you've got to step back and examine my basic point: poll is dying in core. Poll cannot be developed in core because the modules and frameworks which now exist and which could make poll great, will never be in core. Thus one cannot develop poll in such a way as to use these frameworks, thus nobody cares about poll, thus poll is dying. Bringing it out of core will free it to be developed.

The discussion about golden modules and distributions is to be had somewhere else, don't do it on this issue, please.

Why can't someone just develop an advanced poll module, so that the basic one stays in drupal core? It seems like there was one that was being developed, but I'm not sure. If one works well, it could be documented inside of drupal for those that want advanced functionality.

Just my $.02.

Have no fear of removal from core. It doesn't mean that the module is thrown away, it just means that it a) doesn't get packaged with the main Drupal download, and b) doesn't have to meet all the stringent requirements that core modules must meet.

Ask yourself this: if you want a feature for the poll module, and you write a patch, whom are you going to best be able to convince to commit it; a core maintainer that is busy with the forms API and protecting Drupal from XSS attacks? Or the polls module maintainer who is doing the job because of a specific interest in the poll module?

Google summer project?

5 minutes ago - i didn't even know what a XSS attack was: had to look it up.

Shame we can't teach these people with all that energy to write modules instead :-)

+1

I'd prefer to see it developed in a more generalized context using the Voting API. And I like slim frameworks.
--
Stefan Kudwien
www.unleashedmind.com

Ok, +1 to removing it.

I have had a better experience with individual module developers, for the most part, than with core developers. At least having to do with getting something done, which is understandable..

+1 for removing it.

There's enough irritating problems with this module (my personal favorite is this) that are being ignored that it is in dire need of becoming a seperate module where someone can own it easier.

The Advanced Poll project seeks to eventually become high-quality enough to justify removing poll from core. We believe that this may be a possibility for Drupal 6.

+1

ChrisKennedy - great news! I'm still in favor of trimming core. Is there and upgrade path from poll to advanced poll?

Good question, I hadn't even though of the need for that. I'll add that to the roadmap & issue queue.

+1 to the general idea behind this. The poll.module is lacking behind. One cant even set a redirect path after a votes without hacking the code.

The actual module (or block more precisely) HTML is a major overkill and can use some simplification. If advanced poll reaches a stable enough release that allows an upgrade path then I am in favour of replacing poll.module with advanced_poll.module for Drupal 6.

+1 for removing it. Drupal is a light weight modular framework and polls aren't suppose to be a vital part of that.

Let's see whether the CVS log supports the dying claim or not. In the last two years, the only feature we added is inspect and cancel and nothing else. Even that issue begins with

I don't know if poll.module is really considered "core" in the same sense as the truly core parts of drupal. it's a nice module and all, but it's optional, not central to the proper functioning of all drupal sites.

Also, the poll code is simply bizarre at some places. It really seems noone cares.

I read back more -- four years and no features added...

the poll code is simply bizarre at some places

Amen to that, brother.

Anybody agree with this insanity?

+1 to remove it, since nothing is built on top of it.

Almost any poll or voting module relies von Voting API.
We should concentrate on removing poll module from core and replacing it with Voting API.
Having Voting API in core would make rather sense to me.

VotingAPI in core is unlikely and not the topic of this issue. I'm marking this ready to be committed even though there is no patch attached. The day the module is removed from core, I will make a contrib project for it and promise to maintain it for one release cycle.

Poll module stays in core, and I'm accepting patches for improvement.

You mean, you accept voting API in core?

-1 to remove the poll module from core.

Arguements :
- Others have it. Joumbla, etc.
- Polls are fun.
- Polls is a good feature to have from start. Unless there is a very easy web-installer online, like Gallery 2.2.rc2, where one clic does it all (download, install, configure the basic).

Somehow if you have the one clic install, you can remove a lot of others from core. For those who are saying that there is a security trade-off, I'll say that you are right. There are always security trade-off whatever you do. End of story.

1-Not assigned
2-Dries said it stays
3-This issues is close.

In case anyone is interested, Advanced Poll now has a migration path from Drupal Polls as of two weeks ago: http://drupal.org/node/102139

I agree this should be removed from core.

Personally I reckon the overall issue could be dealt with by two or three core install profiles (with those modules not in the install profile not in the download), so that the CMS-type modules can be developed outside core in x.x-1.x and x.x-2.x branches whilst still offering something recognisable as a CMS to new users. More arguments in favour of this here: http://groups.drupal.org/node/6143

Bump: I forgot about this issue, so I just submitted a duplicate a few hours ago and already got enthusiastic support from 7 members of the community, including Moshe:

http://drupal.org/node/200427

What triggered it was realizing that http://drupal.org/node/67895 is still open. It's a critical data-loss bug that's been open for about 1.5 years. Apparently, no one actually uses poll.module enough to care about fixing it. So, either poll should get out of core (yes please!!!), or that issue is a critical bug that should block the 6.0 release. But, we shouldn't release another version of core that contains such broken code. If this gets postponed again, we need to bump the priority on #67895.

Advanced poll in contrib (http://drupal.org/project/advpoll) boasts:

Migration: convert regular Drupal polls into Advanced Polls.

So, it looks like the "but what about a migration path?" question is already solved....

Poll is one of the least used parts of core, it's very broken, it frequently slows down other core development (the FAPI regression test), and many of the leading members of the development community want it to go. Advance poll already provides migration, is maintained by a respected member of the community (ChrisKennedy), and is built on top of the VotingAPI (eaton). Furthermore, if someone wanted to adopt the existing poll module as it moves out of core (much like the drupal.module that we recently dropped), that's fine too, and they can worry about fixing it, maintaining it, porting it to VotingAPI, updating to D7, etc. http://drupal.org/project/poll is even still available. ;)

I've yet to hear a good reason for poll to stay in core for the 6.0 release. If there is one, bring it on. ;) Otherwise, poll should go.

I have tested the core Poll module recently and was really disappointed by its features. It took me 5 minutes to install Advanced Poll, it works great, and the included default set of features are really noteworthy.
Thus, I'd say that having the current Poll module in core won't help anyone.

Additionally, we have great support for install profiles now. If there is a demand to have a (bloated) install profile like Joomla, we can create one.

I use the core poll module (phpbb2drupal imports them ok so we just switched it on in 4.7) and there's nothing good about it. It's got a whole range of issues (auth. users can vote multiple times with multiple sessions for example, which means the block switches from options to results seemingly at random) and it would be an immediate "won't fix" if someone submitted it to core today.

Rickvug said on the dup. issue:

asking users to migrate to something with many features that they've never seen, and likely don't need, could be confusing.

If people don't want new features, they don't have to upgrade to 6.x at all. The biggest improvement that could've happened to poll, drag and drop, didn't get in - for good reasons - some of them being that it would highlight the shortcomings.

If people think Advanced Poll is too much of a jump for an upgrade path this late in the cycle, then I'd suggest moving poll.module into contrib and immediately deprecating it in favour of Advanced Poll (maybe security patches if someone's prepared to take that on). Then we have the best of all possible worlds and it gives people a few months transition if they need it.

Good suggestion Catch.poll.module moves to Contrib as is. There is no need for users to migrate elsewhere if they are happy with their data loss. +1. People can keep chiming in on this issue, but I think it is ready for CVS review again. That data loss bug is new information.

+1 to move poll.module. I am a new adopter of Drupal (about 6 months into use). One of the few disappointments I had at the beginning were poll, I was thinking since it was core it should be a solid module. However, I came across many spots that lack usability, and the one main bug that hit me was the data loss on editing. I quickly went to see what the community contributed, and have not enabled it for any of my projects. Thought I would reflect my personal experience with it.

Guys, are you serious with removing a core module from Drupal after beta 4 and hopefully right before rc1? This bug was there for such a long time, and I have not seen it being critical for any release before. Also I am not sure it is so critical to warrant the removal of the module. Despite shortcomings, poll does its job of collecting simple polls. The built in stats module is just as simple, and is not enough for most sites, the built-in listings are just as simple, and not enough for most sites. The built-in profile module is just as limited, and not enough for some sites. IMHO poll is not any different.

Although I planned to take my time tomorrow with IMHO more critical bugs for Drupal 6, I'll definitely take this on, even improve on the UI and fix the data loss bug. As far as I see, all it takes is to sit down and think through how the data is used there. Let's meet at http://drupal.org/node/67895 if you care.

Whenever 7.x opens for development, make sure to propose this sooner then past beta 4, if you are serious.

The built in stats module is just as simple, and is not enough for most sites, the built-in listings are just as simple, and not enough for most sites. The built-in profile module is just as limited, and not enough for some sites. IMHO poll is not any different.

Similar arguments apply although less dramatically in those cases because I'm not aware of any release blockers for those modules.

Whenever 7.x opens for development, make sure to propose this sooner then past beta 4, if you are serious.

robertDouglass - May 1, 2006 - 18:14

It's also been bumped repeatedly since then, during this cycle.

edit: I didn't actually mean to change status, but this should stay open while the bug is, in my opinion. We have the module ported, we have namespace in contrib cvs, and we have a long term upgrade path, so happening late in the cycle isn't too much of an issue imo.

+1. I'm totally on catch's side. I don't see the problem with removing this from core, either, even if it is that late in release cycle.

Fact is:

• (Quite) nobody uses poll.module.
• Nobody develops for poll.module.
• Nobody cares about poll.module.
• For those who want to use it, we have it in contrib for D6.
• For those who want to move to advanced poll, we're having an upgrade path.

We have to move the module to contrib, cover this in our upgrade documentation, and that's it. Some issues are too late to be fixed now, but this one is certainly not.

P.S. Some kind of Voting API in core would be great, especially as we are known as a CMS that is strong in community features. But that's another point and it is something to think about for D7.

@Gabor: there are many other poll bugs, not just the critical data loss bug:

http://drupal.org/project/issues/drupal?components=poll.module&categorie...

I'm advocating the fastest way to get to a stable D6 release for core is to remove poll instead of trying to fix it. We have vastly more important and far-reaching bugs to be spending our time/energy on than anything in the proceeding query. ;)

As others have pointed out, this isn't a "radical" change to core this late in the cycle. There's are multiple upgrade paths available to existing poll users. It's one minor extra step for a handful of users upgrading to D6, and it a) removes a chunk of unloved, broken code from core, b) would let us focus on fixing bugs that are actually critical, and c) makes development of poll.module possible again.

Thanks for your reconsideration,
-Derek

I still fully support the removal of this module from core. I haven't encountered any arguments that I find convincing for keeping it in core. If we want regression tests we should write test cases. The timing with regards to the release cycle is also of no concern to me. We get D6 sooner without poll - yay, that's better.

Well, I sat down and took one hour on that scarily depicted poll module queue. Identified the following outstanding issues:

- 5.x and 6.x had a missing db_rewrite_sql() in the poll pager count query, RTBC for 5.x, committed to 6.x
- 4.7.x does not have a count query there, so the pager is still broken there
- two UI improvement ideas for poll module moved to 7.x
- with page caching enabled, only one anon user can vote (who's surprised?), this is how page caching works by now, poll cannot work around this, 7.x to improve caching in general in Drupal

So three bugs open for 5.x/6.x:

- form_values is not working for a guy, so he cannot ask for more poll options; I cannot reproduce, and from the looks of the code it looks right
- poll editing clears votes (huh, this bug heated up the remove poll craze)
- poll *choices* are removed in some cases (I am investigating this)

This does not seem like end of the world to me.

Gábor, thank you for looking that closely at the queue.

The bug may have heated up the queue, but the bigger issue is most people just don't like this module, don't use it, resent having to write code for it (when making core changes), and think that it would be better served by putting it in contrib and letting interested parties decide whether it gets maintained. This was a very good decision for Drupal when we moved the archive module into contrib, and I'm 100% confident that poll would die an equally unloved death, primarily because there are better options.

@Gábor, Even if you fix the bugs in the poll module that doesnt change the fact that no one uses it, no one wants it.

I don't remember how late was archive module removed, but in the current case I see we fixed what feature set we have in Drupal 6 a few months ago, so it would have been an opportunity back then to remove stuff. Now we are fixing issues in what we have, neither removing, neither adding stuff to it.

@Gábor: I'm not going to try to push you against your will to remove this for D6 (though that would be my preference). I'm totally comfortable removing it at this point in the cycle, but I encourage anyone who is uncomfortable with the decision to speak up. We can remove it from D7. However, the comments here do send one clear message - and that is very few people are willing to waste their time bugfixing a module that they don't care about.

Well, I guess we should surrender, as this discussion doesn't seem to be about arguments, but about rules and authority. Dries and Gábor just don't want poll.module to be removed in D6. And technically there's no room for discussion, as features have been already frozen.
I actually don't care that much about a dead module in Drupal 6 core. I won't enable it, and thus it won't bother me.

So let's restart the discussion for D7. The big questions are IMHO:

1. Do we want to have some kind of voting capabilities in D7?
2. If yes: How generic or how special should it be? More APIish or some features that allow us to say "We also have voting!"
3. If APIish:
   • Let's collect the features and capabilities our core Voting API should have.
   • Are there good starting points in contrib or do we want to develop something new?
   • Finally: How can we make sure this is generic enough, so it will be the basis for some 95% of all contrib voting modules out there?

Think that this will lead us towards a more encouraging discussion.

In terms of precedent, Drupal module is the most recent example, not that long ago.

Pancho in terms of what should and shouldn't be in core - I think there's a wider question of whether any cms type stuff should be in core at all, especially as install profiles develop.

robertDouglass: it would be interesting to compare the Drupal 5 poll module to the Drupal 6 poll module, and then say whether nobody cared to work on it, I looked into the CVS logs:

- errors were fixed for E_ALL compliance
- merlinofchaos pointed out on IRC that he did considerable work to upgrade the module to proper FAPI 3 use in Drupal 6
- he also tplified the module (nice huge diff at: http://cvs.drupal.org/viewvc.py/drupal/drupal/modules/poll/poll.module?r...)
- reverse proxy, node_load() cache, etc. improvements all improved the module in different patches
- Crell split the module into multiple parts
- quicksketch et. al. improved on the UI and added AHAH poll option addition, one of the very few AHAH form showcases in Drupal 6
- blakehall, JirkaRybka, catch improved on its permission names to be more usable
- in GHOP and out of GHOP, the help texts were improved, the content type description was replaced
- I am into fixing whatever very old bugs come up

These are the main things improved in poll module between Drupal 5 and 6. quicksketch et. al. also proposed a patch to add drag and drop support which would have also fixed the bad db table design, but this was late, so was not committed.

Do we call this "nobody cares about the module"?

@Gabor: I, too, am uninterested in fighting over this. I've already spent way more time thinking/writing about poll module in D6 than it deserves. ;)

I just want to point out that from my perspective, at least 1/2 of your list up there falls into my "poll module slows down core development by forcing people to work on it who don't otherwise care" category. ;) E_ALL, FAPI3, tplification, reverse proxy/node_load caching, module split... I thank everyone who worked on this things, but if you asked them, I'd bet they'd answer "yeah, change X was my baby, so I had to get poll to support it too or it wouldn't have been committed".

Basically, the only new feature from your list that people did specifically *for* poll, because they wanted to, was the UI/AHAH thing, and even that was probably motivated by "this feature is cool, where's something we could use to show it off? i guess poll would do", not "poll's so great, and i use it on all my sites, so i want to make it rock!". The other few remaining changes were bug fixes: fixing the permission names, fixing the help text, etc.

So, I'm not convinced this is a strong evidence to support the theory that lots of people care about this module. But, as I said at the top, I'm not arguing about it anymore... ;)

I will not claim to speak for anyone else, but my reason for page-splitting poll was "it's in core, so I may as well". There were several other modules where that was the case, too. It was not because I particularly like poll module. :-) I am in favor of it moving to contrib and letting Darwin take its course, as long as there is an upgrade path for it (to the contrib, to adv_poll, or whatever).

That said, I am inclined to agree with Gabor. We're at beta 4 state, we're six months past theoretical code freeze, and we've already violated that code freeze a couple of times. :-) Unless poll is unfixable for D6, let's plan and agree right now that once D7 opens up, poll module gets dropped within the first month. (If we don't, this issue will get forgotten until D7-beta4 and we'll have the same conversation all over again.)

I'd be ok with removing poll if we have full unit tests for core. It /is/ our regression test, after all. :P

I do concur that removing a module from core will make core development times faster, which by itself may be a worthy goal. But thinking that we're going to somehow magically end up with a better poll module because we put it in contrib is a pipe dream, imo, and not supported by facts/evidence.

The old Drupal module, Site Network, thusfar hasn't seen /any/ commits since October 8/9, 2007 when it was removed from core: http://drupal.org/project/cvs/181692. That's over 2 months now.

And it looks like it took the old Archive module from core over a year to get a new maintainer interested in expanding its feature set: http://drupal.org/project/cvs/77690

The arguments made here against poll module could easily apply like half the modules in core:
- Aggregator, which was completely broken > 50% of our dev cycle in 6.x
- Blog module, a constant source of usability headaches for the single-user blog case.
- BlogAPI, which hasn't been updated in earnest since over a year ago.
- Forum, which saw some love this time around, but is still light-years behind dedicated systems like PHPBB
- Ping, same boat as BlogAPI.
- Profile, another source of bugs, and a performance drain on heavy-traffic sites.
- Throttle, which d.o doesn't even use. :P
- Tracker, the source of our most damanging query, performance-wise
- Upload, which is another constant source of bugs that no one in their right mind wants to touch.

So looking at that list, we'd be removing all of the features which put Drupal ahead of its time when they were conceived, along with PoC code for features such as our File API, and over half of what makes Drupal a "community" management system. Our core development cycles would likely be much faster without these things, true. But we would also eliminate a lot of what makes Drupal competitive in the more than "just" a framework area.

Thus far, moving something to contrib is at best a crap-shoot, at worst a death sentence. It also makes things more difficult for our users. Instead of "Let me start by what's offered in core and then move on to add-on modules for this feature," it becomes "Crap. Which of these 30 modules that all seem to do the same thing do I use for feature X?" It also makes our beta testing of core more useless. Right now, almost the only things that are getting tested are things in core, since contrib lags so far behind porting things. And unless we include functionality that tests the limits of things like Form API, we're not going to find out things like, "Oh, crap. It turns out multi-page forms are completely broken." until /way/ too late to fix them without causing a lot of pain.

Despite all of this, I am roughly neutral for removing poll in 7.x, however I just want to make sure we are taking all of these things into consideration before we go hog-wild.

Oh, but absolutely -1 for removing Poll module for D6. We got away with that in Drupal module only because we had a suitable replacement that was superior in every way.

I've nothing great to say here, except my personal approach to core modules: I care most about the ones, that my production site runs. I believe, most of us do it this way, more or less. From this angle of view, poll module is one of the more important ones for me, while other modules I don't care about entirely (quite a few others in core). Matter of taste, I would say. Also I think there are other such 'basic' modules in core, for example I wonder why we even have the blog.module, when it does nothing more than a custom basic content type, and a few node listings (well possible through Views), tracker.module (on my site Views replaces it entirely), etc.

As for the poll problems - on my site, anonymous users can't vote (as well as they can't post comments - we're interested about members' opinions, not just passing-by spammers), and I don't even think that granting permissions for editing own polls is a good idea (changing the question makes the whole months-collected poll results unreliable a lot). The only problem I ever had with poll module was, when another admin misunderstood something and added a new option to a running poll (resulted in everyone being able to vote again). But still, we saw much bigger bugs in core already (comment-jumps, luckily now fixed, for example).

The drupal.module was, I believe, removed under a bit different conditions: OpenId sort-of replaced it, so core in fact didn't loose any functionality. We don't need two modules for the same, IMO.

So as for me, -1 to removal.

Note that as it looks like poll module's issue queue is cleaned up. There are two trivial RTBC fixes for 5.x, one user notification improvement sitting for review when it comes to anonymous polling and page caching in Drupal 6, which will not work together, a 7.x feature suggestion and a missing pager in 4.7.x, which I would not fix as 4.7.x is reaching its end of life very soon now.

So one more issue against 6.x, then 6.x is without issues as far as the poll queue goes.

Here's a patch.

Hohum. If we're going to move it to contrib, perhaps it would be better if someone with filesystem access "simply" moved the files (so that commit/revision history was preserved)? (Or it might be better to remove the files and import them in contrib, seeing the status of 6.x CCK...)

Also, is this really critical? The data loss issue was taken care of, right?

There's currently the Advanced Poll module in contrib (which uses Voting API and has more options), and Pollfield module (which supposed to be functionally identical to poll.module except for providing a CCK field instead of a node type). Both modules provide an update path from the core poll tables afaik, although Advanced Poll is more actively maintained.

I'm going to downgrade this from critical, fair point. A few people have mentioned that poll.module currently provides core's best FAPI regression test (note that commenting on polls has been broken in HEAD for two months which I guess is a suitable example). I can understand wanting to keep it in for that reason, although I don't think this particularly helps people who want polls on their site, so it'd be better long term to either write a regression test, or use another complex form if one gets added to core later, if that's the main reason put forward to keep it in core.

Here's a working patch with a CHANGELOG.txt entry.

A few people have mentioned that poll.module currently provides core's best FAPI regression test
As soon as SimpleTest is in core this point should be moot, shouldn't it?

@Freso: It depends on how good our tests are. To date, nothing has tested the Form API quite like the Poll module... it's a multistep form, and a node form at that, with a collection of fields in each grouping. We could write some fake form arrays to test the crap out of FAPI, but Poll module proves that it's actually usable.

The module is a half-dead branch hanging from the Drupal tree. There are better alternatives, with upgrade paths. Moving it to contrib won't fix Poll. Keeping it in core won't fix it.

I'd suggest moving it from core, and giving the namespace to one of the alternatives (probably advanced poll), so long as the maintainers promise to also maintain that upgrade path. That way, the cruft is gone, the module is instantly made far superior, and being in contrib allows a more robust evolutionary path.

-1 for advanced poll taking the place of poll in contrib. That module does WAY more than a simple PHPBB-esque Poll module replacement, which is what most people use it for.

see the title of this issue. thats not being proposed. the issue creator proposes to move poll.module into contrib where interested people can use it OR use advanced poll or whatever. please, no straw men to derail the conversation..

We need to the test the preview and the creation of a node form that adds elements on the press of a button utilizing AHAH. Currently this is done by the poll module and the poll test and it very nicely catched a lot of form API errors. I suggest adding a path to node_menu, put the code into node.test.inc and add a test for it. Borrowing code from poll.module and poll.test is allowed :)

I've no desire to remove poll from core -- certainly not at this point in the development cycle. I think we should make poll module better, and open new issues to fix whatever needs fixing.

<disgruntled>
#62: certainly not at this point in the development cycle ("early")
#35: removing a core module from Drupal after beta 4 and hopefully right before rc1? ("late")
</disgruntled>

Seems there's no "good" time to do this. Let's be honest here: Dries loves poll.module, so it will stay in core (presumably, forever). ;) The rest of us have better things to spend our time on than lost causes such as this...

Never say never.

If it stays in, we ought to unbreak it though: http://drupal.org/node/216515

+1 for removing poll from core.

From an administrator's point of view, I typically do not use many core modules (poll, profile, blog, forum, book, etc..). Most of the functionality can either be duplicated with CCK/Views or is not important enough for my sites to use. This is why having an API for CCK and views in core is one HUGE step in the right direction. Core modules should be nothing but a API so we can extend Drupal.

I can understand Dries motives for keeping it in and respect his viewpoints, I just don't think its forward thinking. I do agree with the community that "core" should not rely on contrib modules.

I think most of the modules I mentioned earlier were great when they were the only option, but things have changed. Drupal is moving away from a CMS and into more of a CMF.

I am not sure about moving one module out of core and adding another, would this mean that if we put Advanced Poll into core, would it still be maintained the way it is? Or should we just move poll (and book,forum,etc,,) out and leave them out?

I don't really have the answer to this, but I do think we need to embrace forward thinking code as opposed to hanging on to old or rarely used code.

+1 for a poll API in core but not a whole module.

How do you report bugs in poll since it's a core module?

I am getting the following:

Hilalsuhaib open a new issue at http://drupal.org/project/issues/drupal/bug and choose the 'poll.module' component.

It's been a couple of months since this was discussed. Any progress on this issue?

1) Dries doesn't want poll.module removed from core (#62), which makes perfect sense, esp. after poll.module got a bunch of much-needed bug fixes prior to the D6 release. 2) If there were any "progress" on this issue it would (kind of obviously?) be posted here.

This is postponed until Drupal decides that core is going to be a framework, we rip out modules like poll and blog, and provide different bundled installation profiles for different kinds of sites. Given the direction of the d7ux stuff, I doubt this is going to happen in D7, maybe never. I still think "won't fix" is the more accurate status, but catch seems to think "postponed". /me shrugs

Also, please don't use "maintainer needs more info" unless you're a maintainer asking for more information from someone who posted an incomplete issue that doesn't clearly explain the bug or feature being discussed. See http://drupal.org/node/156119#postponed-maintainer-needs-more-info for more. Thanks.

Has there been any attempt to turn poll into a field instead of its own node?