Hello Appian Engineering,
Like to suggest :
Scenario :
When a developer working on any object rules ,
It could be UI or expression or model
Appian always had version from past 12plus years
Which is good
As we progress it will be good to have save and commit
1. Save basically a developer works whole day in dev and keep saving not to lose his work but that does not mean it’s working and ready for others to use
2. Commit when developer decides it’s ready for checkin and can be used in site other he needs to commit and mandatory to write comments
May be a ticket that developer is working against or an enhancement for targeting a particular release
Many times we see 100s of versions but more than 75% are just saves of a line change and dev testing how it looks etc and after ten saves developer decides good for real change and closes that piece of work
Just compare how eclipse or vscode git integration works
Even further shelving concept from Microsoft
Having been 12yrs with appian tech
I feel this will be great feature
As of 2022.3 I have not seen
The designer landing page is awesome though
Rayudu A
Discussion posts and replies are publicly visible
Actually, that is a great idea but there are some arguments to it.
Other competing products has this for a decade . Many appian favs(inc me) may not like to say but pega has this for almost a decade
Checkout check in private edit mandatory or optional comments
While I think it would be a great feature to be able to add a comment when saving objects, Appian is about using low-code to make our live easier. Adding more complex behaviour in managing objects will not help in this. Changing our minds and adapting our way of working, will.
Low code does not mean that .
We should have a way to comment the work checked in.
It’s not about complexity , it’s about support and maintaining the code , especially appian says low code , reality all sr devs know how much sail code one writes,
In a group of developers working comments helps to why things changes and for what ticket is changed etc
Often a new dev comes and sees something changed and no idea why it’s changed and person who did it also doesn’t remember
I personally add /* */ at end of rule UI and keep adding and encourage teams
Ex
/* v91- rayudu changed for fixing. Ticket 123 and some explanation of why and why logic changed and deployed in release dates 2022-05-30 /*
I'd argue that seeing a comment along the version number would make my life easier rather than having to compare with previous version to see when a change was introduced ;)
There could be a toggle to make comments optional (either at Application or Platform level) if you don't want to be impacted by the change.