danwatford commented on pull request #466: URL: https://github.com/apache/ofbiz-framework/pull/466#issuecomment-1023262012
Hi Pierre, So my difficulty is assessing this PR is that it is changing two different levels of implementation. The first category of changes are the switch from list forms to grids. This is a technical change where the same pattern of changes can be applied again and again with low risk, allowing the committer to easily comprehend intent. As soon as we consider the second category of label changes, i.e. the application level, we then need the committer to understand the intention of the application - in this case the HR application and how job requisitions, applications, interviews and relocations work. I personally do not have a good knowledge of that application and have to spend a long time trying to figure out what the original intention was behind the application, and whether the application is broken in some way or whether there is a misunderstanding on the part of the contributor. See rules 1 and 2 here - https://cwiki.apache.org/confluence/display/OFBIZ/OFBiz+Committers+Roles+and+Responsibilities The application intent also applies to labels. In the case of position as pertaining to employment, this is similar to the meaning of role. But in English position can also refer to location, status, etc. I only speak one language so have to err on the side of caution when generalising labels as I don't know if it will cause trouble for other languages. In this specific case I thought it better to return to the hard-coded title, Employee Name, since it seemed the safest way of not breaking the intention of the HR application - or at least not making the intention any worse. You mentioned the use of ${groupName} being an indicator that groups, in addition to individuals, can be provided relocation. I wouldn't have expected that to be the intention of the HR application in this case, so it may be the case that use of ${groupName} is incorrect in this case, rather than the use of the title 'Employee Name', accepting that hard-coded values are not great. I don't know which is the case and would need to investigate further. Getting up to speed on the HR application will take time, therefore moving and discussing application intent changes to a different jira ticket or the mailing list would be my preference, hence my reverting of the labelling changes on this PR where there is the potential for ambiguity across languages. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
