To reply to the original question, a distinction appears to be made by the project between feature requests ("please implement this and this because I want it") and feature discussions ("I feel that if the software would do this, it would be much better. It could be implemented such and such. What do others think?"). Especially to newcomers, this can be confusing (the latter is what I would call a feature request, the former is not really worth the effort of picking words to describe it
![Smile :)](./images/smilies/icon_e_smile.gif)
). But, since most people seem to think the former form is a perfectly valid way of making a feature request, I suppose it is a good distinction to be made.
About your suggestion. There's a lot to consider. How would you fit roles, groups and users into this scheme? Do you suggest to drop funcitonality from the system, and if so, which?
With rows of permissions and columns of user groups, fields could be the standard choice between yes, no and never (other projects use a similar system, but with checkmarks in the fields, i.e. choices yes and no). Alternatively, rows and colums could be swapped, at the expense of going against convention, but with the benefit the layout would be similar to the permissions masks.
Assigning roles could be done using a drop down associated with the group. Using AJAX, selecting a role should update the permissions settings in the grid immediately, so people can immediately see and understand the implications of selecting a role. Assigning permissions to roles would be done through a similar system, although maybe the possibility of changing roles should be subdued a little (I think that phpBB having both roles and groups can be confusing, especially as some other systems have either groups or roles - in which case role is just another word for group). Maybe the possibility of changing roles by the user should be removed altogether, degrading them to simple presets, and leaving the finetuning to editing group permissions.
This leaves assigning permissions to individual users. This could actually be an adaptation of the overall groups screen, with a single row (if groups were rows) at the bottom added for that individual users. With a little AJAX, that view could even double as a permission masks view, where manipulating the user's individual setting will immediately reflect the end result for a particular permission.
Alternatively, settings for individual users could be dropped too. I think it adds to the confusion, while the functional benefits are minimal (and it might lure users in a far too complex set of permissions settings, because they are controlling permissions for individual users where they could/should be using user groups).