以下嘴砲，加減參考就好。
個人建議是自己先弄出一個基本雛形，
讓人可以簡單的直接套用或修改。
大前提是讓別人可以用現在一半以下的力氣達到相同效果，
要學的也盡可能少 (都包好給人直接執行或抄)。
新工具 (測試/版控/相依性) 就看看能不能用命令操作，
能就自己把環境弄好，把命令包好，
讓其他人可以直接執行某些你給的 script 就收工。
(ex 輸入 project path 就自動做完以下
傳到遠方你架的環境 -> 更新 lib -> 在你的環境跑測試 -> 沒錯就 commit)
這部份要做的事簡單摘要如下：
1. 架設環境。
2. 練習並摸熟操作方式/命令。
3. 將過去專案需要的功能寫成可單鍵/一個命令執行的 script。
4. 將 3 的 script 做到可在任一機器上執行。
5. 準備好任何誤用 (誤刪/誤 commit/拉錯 lib/etc) 情形下的解決方案。
然後只要把 script 公開讓人取用，
有人想用就用，沒人想用可以自己用，
然後假設那真的很有用但除了你沒其他人用的話，
你做事應該就會有別人 N 倍的效率，
有助於你爬到能主導的位置或幾年後以戰功/能力跳槽。
新語法就寫個 sample 分 A B 兩組，
A 用目前語法，B 用新語法，然後分析利弊得失，
寫成文章公開給人存取並提供完整可執行專案。
這部份有幾點要注意/實行：
1. 語法整理
前面 ${} 像 jQuery 雖然有點 XD，
但不是全無道理，依字型/大小等確實可能增加辨識的麻煩，
那再考慮是否以 noconflict 把 jQuery 換個變數名與 $ 區分，
能不能簡單的 replace 所有檔案。
2. 功能確認
原本用的 tag 是不是有哪些特別功能，
例如會存資料到 Request/Session Scope，
或者有親子/連動等功能或特性，
要換有沒有辦法全換掉？
或者能不能整理出一套相對單純而好記好用的 pattern？
例如什麼 case 用 EL，什麼時候用 tag，
如何組合，有什麼原則或要注意的地方等等。
3. 還是功能確認
假設某些 case 你發現 EL 超好用，
那麼假設不用 EL 只用目前的東西，
目前的用法有其它改進空間嗎？
這部份要花 3 倍的時間去做，
例如原本花 2 小時研究發現 EL 超好用，
那就花 6 小時研究不用 EL 的話最好能做到如何，
要比較兩個東西就要把它們都發揮到淋漓盡至，
這是要向別人推銷之前的基本禮貌。
這樣推成當然好，推不成你也學了不少更有本錢跳槽。
※ 引述《dream1124 (全新開始)》之銘言：
43
: 那是不是以後專案都不可能引入新工具了?
: 結果他竟然很誠懇的說: "對, 確實是不太想導入其他工具!"
: 我了解他是不想唬弄我才會很直接的說,
: 但回去以後越想越氣, 怎麼連這麼小的事情都說不給一點彈性, 方便, 與進步呢?
: 實在是有些不爽, 很想找機會跟前輩上面的人反應這個問題,
: 或是在個人例行報告的會議裡面向同部門的人反應我的心聲和想法,
: 可是直覺又告訴我這樣也許效果不會好, 又會有些可能的副作用,
: 因此上來請問大家一下, 若是你, 會怎麼做呢?
: 謝謝大家