Hi Michael, congratulation first and thanks for your prompt reply. It is amazing how you can be so attentive to the community.
For (c), I think you misunderstood my point, I am not saying to make modules re-usable by exposing the function/method directly, instead, I against them as it will make the module common very bulky. I am saying to have a way to launch a sub-task within a custom module (task) in order to reuse the existing goodness, e.g. I want to put a file to S3 in my module, why I need to use low level api such as boto when I can re-use the existing s3 task - just one line!
For (d), I am reasoning using common sense only, e.g. 10gen distribute the mongodb playbook, declared the default port of 27017 in the playbook, and I am using group_vars to manage mongodb replica sets at different datacenters, either I am satisfying with the default in the playbook, or otherwise, I can simply override them in my group_vars. I don't want to modify the playbook and 10gen can't access my group_vars, to me or people in the mailing list, it make a lot of sense to have the defaults in the playbook. To keep things minimal, honestly, you don't need to introduce new stuff for this, just revert it by changing the priority in the next major release and give people enough warnings and people will understand.
While I see your point on (C), there are characteristics of ansible that have led to that point, such as zero-boostrapping and keeping things very efficient. So yes, I agree that's true, but it hasn't been much of a problem so far.
(D) We're pretty big about backwards compat, so I'm definitely not going to be reverting any priorities. I think a lot of people DO like the way things are set up now. I'm open to including a 'defaults/' type directory in roles though and that's something we are exploring for those that want to ship defaults and don't want to edit their group_vars for whatever reason.
For (c), I think you misunderstood my point, I am not saying to make modules re-usable by exposing the function/method directly, instead, I against them as it will make the module common very bulky. I am saying to have a way to launch a sub-task within a custom module (task) in order to reuse the existing goodness, e.g. I want to put a file to S3 in my module, why I need to use low level api such as boto when I can re-use the existing s3 task - just one line!
For (d), I am reasoning using common sense only, e.g. 10gen distribute the mongodb playbook, declared the default port of 27017 in the playbook, and I am using group_vars to manage mongodb replica sets at different datacenters, either I am satisfying with the default in the playbook, or otherwise, I can simply override them in my group_vars. I don't want to modify the playbook and 10gen can't access my group_vars, to me or people in the mailing list, it make a lot of sense to have the defaults in the playbook. To keep things minimal, honestly, you don't need to introduce new stuff for this, just revert it by changing the priority in the next major release and give people enough warnings and people will understand.