hey
following the proposal to add Flag module to the Issue tracker, to provide subscribe/unsubscribe links, and the proposal to add remove Actions/Triggers from D8 core (advanced with add Rules to D8 core), i'm presenting an idea:

add Rules module to perform some or all conditional actions when certain events occur, for the drupal.org issue tracker.

following the subscribe/unsubscribe idea logic, Rules for example, could optionally perform email actions, when new comments are added, or on schedule to save resources and reduce amount of mails (like say just once a day with a resume, taken from a View)

... that View being imported to Rules with Rules Views Integration, which allows Rules to execute/include Views and Views to execute Rules.

other things Rules could do:
* co-work with Cache Actions to issue a cleanup on specific caches on Drupal, Views and Panels, assigned to the nid/cid being affected by the Flag
* have Rules and Cache Actions work with Fivestar, Rate and other Voting API modules through Voting Rules.
* alert project maintainers when issues are created
* alert users when their issues are closed
* anything Actions/Triggers already does
etc

there are some supporters of Rules to be used in Core and/or on drupal.org, but there is also some against it, stating that Actions/Triggers is enough, and Rules is too immature and complex.

personally, i think Rules is complex, yes, but it's also mature, not immature, and much, much more powerful. it integrates Token module (something Token Actions in Token bundle also does for Actions), but goes further with PHP support for example, plus much, much more.

let me also state, that while being complex, documentation does exist, and the module does work. once you get the hang on it, it's actually easy to work with it.

regarding support from other modules,
lots of modules supporting Rules have been developed, plus a plethora of integrations.
for example, Drupal Commerce and Ubercart have moved into Rules, and ignored Actions in their planning. and Cache Actions, for example, does not support Actions... only Rules.
the ecosystem is big and gets bigger all the time - many if not all of the major players already support both Actions and Rules.

Rules is also considered by many people, the future of conditional actions in drupal, to supersede Actions and Triggers, Workflow-ng, Conditional Actions and other older modules.

IMO, besides the advantages stated above, as Rules' development goes on and the project is quite active and supported and stable, it makes it a good candidate for drupal.org.

more about rules:
* http://drupal.org/node/34496#comment-4725736
* http://drupal.org/node/764558#comment-4702486
* http://drupal.org/node/1211396
* http://groups.drupal.org/rules/rules-modules
* http://drupal.org/project/modules?filters=bs_project_sandbox%3A0&text=rules

Comments

I am not a fan of rules.module. And there's plenty of understatement in that statement.

not sure what you mean, but if it's about what Rules can't do that Actions/Triggers can do, from the core module, it can do everything, perhaps salvo one event (which i can't remember anymore which was or if it was introduced with Token Actions).

regarding contrib modules that interact with Actions... yes, there are for sure module which support Actions and don't support Rules. of the 10000+ module universe, for sure there are plenty. but of the main modules, i don't think so.

if it's about Rules not being more powerful than Actions... i don't agree.

i did not mention above, but Rules is also more flexible - it allows you to create sets of rules which can be called by other Rules - that allows you to avoid repeating Rule code (DRY/DIE) by re-utilizing the code.

further, you can pass arguments to rules, and make them work on contexts.

Rules is all about Events, Conditions, Actions, Tokens/PHP, Arguments and Contexts/Relationships. also allows for nested conditions (condition groups).

ex
user_post_comment_rule_A (event: when user posts comment):
* if node type = blog OR forum OR poll, publish comment, run alert_ruleset, pass argument content, comment
user_post_comment_rule_B (event: when user posts comment):
* if node type <> blog, run alert_ruleset, pass argument content, comment

alert_ruleset:
* accept argument content, comment
* send email to content author: a comment was published
* send email to comment author: your comment was posted
* send to watchdog: a comment was posted for [node:type]

I'm with killes here, as Rules would be a bit of overkill for Drupal.org (and probably cause slight(?) performance decreases). Rules is great for many (most?) Drupal sites, but for larger/more resource-intense sites, hooking into processes yourself in custom modules (which, I presume, is what drupal.org does) and doing exactly what you need to do will be the better/more maintainable option.

That, and when it comes time to upgrade to D7, manual rules migrations won't need to be done :-)

Let me re-emphasize, though, that Rules is an excellent module... for certain sites.

Status:Active» Postponed

LPCA, I don't want to discourage your desire to improve things at drupal.org. However rules.module seems to me the wrong way. OTOH, you can apply for a dev site, install rules there and show me that I am wrong.

Setting this to postponed.

postponing is a good call. i will look into this when i have some free time. thank you

Status:Postponed» Closed (won't fix)

apparently no free time found.

Status:Closed (won't fix)» Postponed

...actually postponed then. Till time is found ;)