03 ਜਨ 2026·8 ਮਿੰਟ
ਕਮਿਟਾਂ ਅਤੇ ਸਕ੍ਰੀਨਸ਼ਾਟਾਂ ਤੋਂ ਆਟੋਮੈਟਿਕ ਰਿਲੀਜ਼ ਨੋਟਸ
ਕਮਿਟਾਂ ਅਤੇ ਸਕ੍ਰੀਨਸ਼ਾਟਾਂ ਤੋਂ ਆਟੋਮੈਟਿਕ ਰਿਲੀਜ਼ ਨੋਟਸ: ਛੋਟੇ PR ਨੋਟਸ ਅਤੇ UI ਸਨੈੱਪਸ਼ਾਟ ਨੂੰ ਘੱਟ ਹੱਥੋਂ-ਹٿ ਸੰਪਾਦਨ ਨਾਲ ਸਪੱਸ਼ਟ ਚੈਂਜਲੌਗ ਵਿੱਚ ਬਦਲਣ ਦਾ ਸਧਾਰਨ ਵਰਕਫਲੋ।
ਕਮਿਟਾਂ ਅਤੇ ਸਕ੍ਰੀਨਸ਼ਾਟਾਂ ਤੋਂ ਆਟੋਮੈਟਿਕ ਰਿਲੀਜ਼ ਨੋਟਸ: ਛੋਟੇ PR ਨੋਟਸ ਅਤੇ UI ਸਨੈੱਪਸ਼ਾਟ ਨੂੰ ਘੱਟ ਹੱਥੋਂ-ਹٿ ਸੰਪਾਦਨ ਨਾਲ ਸਪੱਸ਼ਟ ਚੈਂਜਲੌਗ ਵਿੱਚ ਬਦਲਣ ਦਾ ਸਧਾਰਨ ਵਰਕਫਲੋ।
ਰਿਲੀਜ਼ ਨੋਟਸ ਉਹਨਾਂ ਕੰਮਾਂ ਵਿੱਚੋਂ ਹਨ ਜਿਨ੍ਹਾਂ ਬਾਰੇ ਹਰ ਕੋਈ ਮੰਨਦਾ ਹੈ ਕਿ ਇਹ ਲਾਭਦਾਇਕ ਹਨ, ਪਰ ਅਕਸਰ ਇਹ ਹਫਤੇ ਦੇ ਅਖੀਰ 'ਚ ਧੱਕੇ ਨਾਲ ਕੀਤੇ ਜਾਂਦੇ ਹਨ ਜਦੋਂ ਊਰਜਾ ਘੱਟ ਹੁੰਦੀ ਹੈ। ਕੁਝ ਤੇਜ਼ ਸਪ੍ਰਿੰਟਾਂ ਤੋਂ ਬਾਅਦ, ਇਹ ਇੱਕ ਝਟਪਟ ਪੈਰਾ ਬਣ ਜਾਂਦੇ ਹਨ ਜਾਂ ਪੂਰੀ ਤਰ੍ਹਾਂ ਛੱਡ ਦਿੱਤੇ ਜਾਂਦੇ ਹਨ।
ਮੁੱਦਾ ਵਕਤੀ ਹੈ। ਵੇਰਵੇ ਕਮਿਟਾਂ, PR ਥ੍ਰੈਡਾਂ ਅਤੇ ਛੋਟੀ ਗੱਲ-ਬਾਤਾਂ ਵਿੱਚ ਹੁੰਦੇ ਹਨ। ਜਦ ਤੁਸੀਂ ਚੈਂਜਲੌਗ ਲਿਖਣ ਬੈਠਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਯਾਦ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਹੇ ਹੁੰਦੇ ਹੋ ਕਿ ਬਦਲਾਅ ਕਿਉਂ ਮਹੱਤਵਪੂਰਨ ਸੀ, ਕਿਸ ਨੂੰ ਲਾਭ ਮਿਲਿਆ, ਅਤੇ ਇੱਕ ਯੂਜ਼ਰ ਅਸਲ ਵਿੱਚ ਕੀ ਨੋਟਿਸ ਕਰੇਗਾ।
ਭਾਸ਼ਾ ਦਾ ਅੰਤਰ ਵੀ ਹੈ। ਡਿਵੈਲਪਰ ਅਜਿਹੀਆਂ ਚੀਜ਼ਾਂ ਲਿਖਦੇ ਹਨ ਜਿਵੇਂ “refactor auth middleware” ਜਾਂ “fix race in cache,” ਪਰ ਯੂਜ਼ਰ ਚਾਹੁੰਦੇ ਹਨ “Sign-in ਹੁਣ ਹੋਰ ਭਰੋਸੇਯੋਗ ਹੈ” ਜਾਂ “ਧੀਮੀ ਕਨੈਕਸ਼ਨਾਂ 'ਤੇ ਪੇਜ ਤੇਜ਼ ਲੋਡ ਹੁੰਦੇ ਹਨ।” ਤਕਨੀਕੀ ਕੰਮ ਨੂੰ ਯੂਜ਼ਰ ਭਾਸ਼ਾ ਵਿੱਚ ਤਬਦੀਲ ਕਰਨਾ ਧਿਆਨ ਮੰਗਦਾ ਹੈ, ਅਤੇ ਸੰਦਰਭ ਬਦਲਦੇ ਸਮੇਂ ਇਹ ਮੁਸ਼ਕਲ ਹੁੰਦਾ ਹੈ।
ਫਾਰਮੈਟਿੰਗ ਵੀ ਮੁੱਦਾ ਬਣ ਜਾਂਦੀ ਹੈ। ਇਕ ਹਫਤਾ ਤੁਸੀਂ ਬੁਲੇਟ ਲਿਖਦੇ ਹੋ, ਦੂਜੇ ਹਫਤੇ ਪੈਰਾਗ੍ਰਾਫ। ਇਕ ਵਿਅਕਤੀ ਐਮੋਜੀ ਜੋੜਦਾ ਹੈ ਤੇ ਦੂਜਾ ਟਿਕਟ ID। ਸਮੇਂ ਦੇ ਨਾਲ, ਚੈਂਜਲੌਗ ਭਰੋਸੇਯੋਗ ਨਹੀਂ ਰਹਿੰਦਾ ਕਿਉਂਕਿ ਪਾਠਕ ਉਹਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਸਕੈਨ ਨਹੀਂ ਕਰ ਸਕਦੇ ਜਾਂ ਰਿਲੀਜ਼ਾਂ ਦੀ ਤੁਲਨਾ ਨਹੀਂ ਕਰ ਸਕਦੇ।
ਚੰਗੀ ਗੱਲ ਇਹ ਹੈ ਕਿ ਤੁਹਾਡੇ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਜ਼ਿਆਦਾਤਰ ਰਾ ਮਾਲ ਮੌਜੂਦ ਹੈ। ਇੱਕ ਛੋਟੀ PR ਵਰਣਨਾ ਅਤੇ ਕੁਝ UI ਸਕ੍ਰੀਨਸ਼ਾਟ ਆਮ ਤੌਰ 'ਤੇ ਸਭ ਕੁਝ ਮੁਹੱਈਆ ਕਰ ਦਿੰਦੇ ਹਨ। ਮਕਸਦ ਨਾਵਲ ਲਿਖਣਾ ਨਹੀਂ — ਇਹ ਹੈ ਇਕਸਾਰ, ਯੂਜ਼ਰ-ਫਰੈਂਡਲੀ ਨੋਟਸ ਘੱਟ ਮਨੁੱਖੀ ਕੰਮ ਨਾਲ ਤਿਆਰ ਕਰਨਾ।
ਸਧਾਰਨ ਦ 접근 ਸਭ ਤੋਂ ਵਧੀਆ ਕੰਮ ਕਰਦਾ ਹੈ:
ਰਿਲੀਜ਼ ਨੋਟਸ ਜੋ ਇਕਸਾਰ ਮਹਿਸੂਸ ਹੁੰਦੀਆਂ ਹਨ ਲਈ, ਉਹ ਇਨਪੁਟਸ ਸਪਸ਼ਟ ਰੱਖੋ ਜੋ ਤੁਹਾਡੇ ਕੋਲ ਮੌਜੂਦ ਹਨ। ਬਹੁਤ ਸਾਰੀਆਂ ਟੀਮਾਂ ਕੋਲ ਕਾਫ਼ੀ ਵੇਰਵਾ ਹੁੰਦਾ ਹੈ — ਉਹ ਸਿਰਫ਼ ਫੈਲਿਆ ਹੋਇਆ ਹੁੰਦਾ ਹੈ।
ਇੱਕ ਕਮਿਟ ਸਭ ਤੋਂ ਛੋਟਾ ਯੂਨਿਟ ਹੈ: ਕੋਡ ਵਿੱਚ ਕੀ ਬਦਲਿਆ, ਉਸ ਦਾ ਤਕਨੀਕੀ ਰਿਕਾਰਡ। ਕਮਿਟ ਸੁਨੇਹੇ ਟਰੇਸਿੰਗ ਲਈ ਪਯੋਗੀ ਹੋ ਸਕਦੇ ਹਨ, ਪਰ ਉਹ ਅਕਸਰ“fix lint” ਜਾਂ “refactor header” ਵਾਂਗ ਲਿਖੇ ਹੁੰਦੇ ਹਨ, ਜੋ ਗਾਹਕ ਨਹੀਂ ਪੜ੍ਹਨਾ ਚਾਹੁੰਦੇ।
ਇੱਕ PR (ਪੁੱਲ ਰਿਕਵੈਸਟ) ਵਰਣਨ ਪੁਲ ਹੈ। ਇਹ ਦੱਸਦਾ ਹੈ ਕਿ ਬਦਲਾਅ ਕਿਉਂ ਹੈ, ਰਿਵਿਊਅਰ ਨੂੰ ਕੀ ਦੇਖਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਪ੍ਰੋਡਕਟ ਨੁਕਤੇ-ਨਜ਼ਰ ਤੋਂ ਕੀ ਬਦਲਿਆ। ਜੇ ਤੁਸੀਂ ਆਟੋਮੈਟਿਕ ਰਿਲੀਜ਼ ਨੋਟਸ ਚਾਹੁੰਦੇ ਹੋ, PR ਵਰਣਨ ਆਮ ਤੌਰ 'ਤੇ ਸਭ ਤੋਂ ਵਧੀਆ ਰਾ ਮਾਲ ਹੁੰਦਾ ਹੈ ਕਿਉਂਕਿ ਇਹ ਸਧਾਰਨ ਭਾਸ਼ਾ ਵਿੱਚ ਲਿਖਿਆ ਜਾ ਸਕਦਾ ਹੈ ਬਿਨਾਂ ਲੰਮਾ ਹੋਏ।
ਇਸ਼ੂ ਸਿਰਲੇਖ (ਜਾਂ ਟਿਕਟ ਸਿਰਲੇਖ) ਇਕ ਹੋਰ ਸਹਾਇਕ ਨਿਸ਼ਾਨੇ ਹਨ: ਇਹ ਸੁੱਤੀ ਸਮੱਸਿਆ ਦਾ ਨਾਮ ਰੱਖਦੇ ਹਨ। ਜਦ PRs ਇਸ਼ੂਆਂ ਦਾ ਹਵਾਲਾ ਦਿੰਦੇ ਹਨ, ਤਾਂ ਤੂੰ ਇੱਕ ਸਾਫ਼ ਥ੍ਰੈਡ ਮਿਲਦਾ ਹੈ “ਰਿਪੋਰਟ ਕੀਤੀ ਸਮੱਸਿਆ” ਤੋਂ “ਸ਼ਿਪ ਕੀਤੀ ਫਿਕਸ” ਤੱਕ।
ਇੱਕ UI ਸਕ੍ਰੀਨਸ਼ਾਟ (ਸਕ੍ਰੀਨਸ਼ਾਟ ਜਾਂ ਛੋਟੀ ਐਨੋਟੇਟ ਕੀਤੀ ਤਸਵੀਰ) ਉਹ ਦ੍ਰਿਸ਼ ਹੈ ਜੋ ਯੂਜ਼ਰ ਅਸਲ ਵਿੱਚ ਦੇਖੇਗਾ। ਇਹ ਸਜਾਵਟ ਨਹੀਂ — ਇਹ ਸਬੂਤ ਅਤੇ ਸੰਦਰਭ ਹੈ।
ਰਿਲੀਜ਼-ਨੋਟ ਆਉਟਪੁੱਟ ਆਮ ਤੌਰ 'ਤੇ ਦੋ ਕਿਸਮਾਂ ਵਿੱਚ ਵੰਨਾ-ਵੰਨਦੇ ਹਨ:
ਮੁੰਝੀਦਾਰੀ ਪੜ੍ਹਨ ਵਾਲੇ ਵੱਖ-ਵੱਖ ਕਾਰਨਾਂ ਲਈ ਇਹ ਨੋਟਸ ਪੜ੍ਹਦੇ ਹਨ। ਗਾਹਕ ਜਾਣਨਾ ਚਾਹੁੰਦੇ ਹਨ ਕਿ ਅੱਜ ਉਨ੍ਹਾਂ ਲਈ ਕੀ ਬਦਲਿਆ। ਸਹਾਇਤਾ ਨੂੰ ਪਤਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਕੀ ਉਮੀਦ ਰੱਖਣੀ ਹੈ ਅਤੇ ਯੂਜ਼ਰਾਂ ਨੂੰ ਕੀ ਦੱਸਣਾ ਹੈ। ਸੇਲਜ਼ ਅਤੇ ਸੱਕਸ ਦੇਖਦੇ ਹਨ ਕਿ ਕੀ ਨਵਾਂ ਹੈ ਅਤੇ ਕੀ ਉਪਯੋਗੀ ਹੈ। ਅੰਦਰੂਨੀ ਟੀਮਾਂ ਨੂੰ ਪਤਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਕੀ ਸ਼ਿਪ ਹੋਇਆ ਅਤੇ ਕੀ ਟੁੱਟ ਸਕਦਾ ਹੈ।
ਸਕ੍ਰੀਨਸ਼ਾਟਸ ਸਭ ਤੋਂ ਲਾਭਦਾਇਕ ਹੁੰਦੇ ਹਨ ਜਦੋਂ ਉਹ ਤਿੰਨ ਗੱਲਾਂ ਵਿੱਚ ਮਦਦ ਕਰਨ: ਬਦਲਾਅ ਦਾ ਸਬੂਤ ਦੇਣਾ, ਸਹੀ ਲੇਬਲ ਅਤੇ ਬਟਨ ਨਾਮ ਯਾਦ ਦਿਵਾਉਣਾ, ਅਤੇ ਪਹਿਲਾਂ/ਬਾਦ ਇੰਝ ਦਿਖਾਉਣਾ ਜੋ ਲਿਖਤ ਨਹੀਂ ਦਿਖਾ ਸਕਦੀ।
ਚੰਗਾ ਚੈਂਜਲੌਗ ਲਿਖਣ ਨਾਲੋਂ ਵੱਧ ਤਰ੍ਹਾਂ ਸੋਰਟ ਕਰਨ ਬਾਰੇ ਹੁੰਦਾ ਹੈ। ਜੇ ਢਾਂਚਾ ਹਰ ਰਿਲੀਜ਼ ਵਿੱਚ ਇੱਕੋ ਜਿਹਾ ਰਹਿੰਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਛੋਟੇ PR ਨੋਟਸ ਨੂੰ ਬਿਨਾਂ ਹਰ ਵਾਰੀ ਫਾਰਮੈਟ ਸੋਚੇ-ਸਮਝੇ ਰਿਲੀਜ਼ ਨੋਟਸ ਵਿੱਚ ਬਦਲ ਸਕਦੇ ਹੋ।
ਉਹ 4 ਤੋਂ 6 ਸ਼੍ਰੇਣੀਆਂ ਚੁਣੋ ਜੋ ਤੁਹਾਡੇ ਉਤਪਾਦ ਬਾਰੇ ਯੂਜ਼ਰਾਂ ਵਰਗੇ ਬੋਲਦੇ ਹਨ। ਬਹੁਤ ਜ਼ਿਆਦਾ ਬਕੈਟ ਤੋੜ-ਮਰੋੜ ਕਰ ਦੇਂਦੇ ਹਨ ਅਤੇ “misc” ਪੈਲ ਬਣਾਉਂਦੇ ਹਨ।
ਇੱਕ ਪ੍ਰਯੋਗਕਾਰੀ ਸੈੱਟ ਹੈ:
“Admin” ਉਪਯੋਗੀ ਹੈ ਜਦੋਂ ਬਦਲਾਅ ਮਲਕਾਂ, ਬਿਲਿੰਗ, ਭੁਮਿਕਾਵਾਂ, ਜਾਂ ਸੈਟਿੰਗਜ਼ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦੇ ਹਨ। ਜੇ ਤੁਹਾਡਾ ਉਤਪਾਦ ਡਿਵੈਲਪਰ-ਮુખੀ ਹੈ ਤਾਂ ਤੁਸੀਂ ਇਸਨੂੰ “API” ਨਾਲ ਬਦਲ ਸਕਦੇ ਹੋ। ਨਾਮ ਸਥਿਰ ਰੱਖੋ ਤਾਂ ਕਿ ਪਾਠਕ ਜਾਣ ਜਾਣ ਕਿੱਥੇ ਦੇਖਣਾ ਹੈ।
ਯੂਜ਼ਰ-ਸਮ੍ਹਣੇ ਅਤੇ ਅੰਦਰੂਨੀ-ਕਿਵੇਂ ਨੂੰ ਸਪਸ਼ਟ ਲਾਈਨ ਨਾਲ ਵੰਡੋ। ਇੱਕ ਸਧਾਰਨ ਨਿਯਮ: ਜੇ ਇੱਕ ਯੂਜ਼ਰ ਇਸਨੂੰ ਨੋਟਿਸ ਕਰ ਸਕਦਾ, ਖੋਜ ਸਕਦਾ ਜਾਂ ਇਸ 'ਤੇ ਨਿਰਭਰ ਕਰ ਸਕਦਾ ਹੈ, ਤਾਂ ਇਸਨੂੰ ਰਿਲੀਜ਼ ਨੋਟਸ ਵਿੱਚ ਰੱਖੋ। ਜੇ ਇਹ ਸਿਰਫ਼ ਰੀਫੈਕਟਰਿੰਗ, ਡਿਪੈਂਡੇੰਸੀ ਬੰਪ, ਜਾਂ ਲੋਗਿੰਗ ਬਦਲਾਵ ਹੈ, ਤਾਂ ਇਹ ਬਾਹਰ ਰੱਖੋ ਜੇਕਰ ਇਹ ਵਿਹਾਰ ਬਦਲਦਾ ਨਹੀਂ।
ਇੱਕ ਵਾਕ ਪੈਟਰਨ ਚੁਣੋ ਅਤੇ ਉਸੇ ਤੇ ਟਿਕੇ ਰਹੋ। ਇਸ ਨਾਲ PR ਵਰਣਨਾਂ ਮਿਨੀ ਨਾਟਕ ਨਹੀਂ ਬਣਦੇ ਅਤੇ ਆਖਰੀ ਨੋਟਸ ਪੜ੍ਹਨ ਲਾਇਕ ਤੇਜ਼ੀ ਨਾਲ ਸਮਝ ਆਉਂਦੇ ਹਨ।
ਇੱਕ ਭਰੋਸੇਯੋਗ ਪੈਟਰਨ ਹੈ:
ਕੀ ਬਦਲਿਆ + ਕਿਸ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕੀਤਾ + ਕਿੱਥੇ ਲੱਭਣਗੇ।
ਉਦਾਹਰਣ: “Added two-factor login for workspace owners in Settings.” ਭਾਵ ਇਹ ਵਾਕ ਪੈਟਰਨ ਬਾਅਦ ਵਿੱਚ ਵੀ ਟੋਨ ਅਨੁਸਾਰ ਬਦਲ ਸਕਦਾ ਹੈ, ਪਰ ਰਾ ਇਨਪੁਟ ਇੱਕਸਾਰ ਰਿਹੈਗਾ।
ਇੱਕ ਛੋਟਾ ਗਲੋਸਰੀ ਬਹੁਤ ਟੀਮਾਂ ਦੀ ਉਮੀਦ ਤੋਂ ਵੱਧ ਮਦਦ ਕਰਦਾ ਹੈ। ਹਰ ਮੁੱਖ ਧਾਰਨਾ ਲਈ ਇੱਕ ਸ਼ਬਦ ਚੁਣੋ ਅਤੇ ਪਰਿ-ਵਰਤੋਂ ਨਾ ਕਰੋ (ਉਦਾਹਰਨ ਵਜੋਂ, ਹਮੇਸ਼ਾਂ “workspace” ਕਹੋ, ਨਾ ਕਿ ਕਦੇ “project” ਤੇ ਕਦੇ “team space”)। ਇਕਸਾਰ ਸ਼ਬਦਾਵਲੀ ਚੈਂਜਲੌਗ ਨੂੰ ਇੱਕ ਆਵਾਜ਼ ਵਾਂਗ ਮਹਿਸੂਸ ਕਰਵਾਉਂਦੀ ਹੈ।
ਆਟੋਮੈਟਿਕ ਰਿਲੀਜ਼ ਨੋਟਸ ਪ੍ਰਾਪਤ ਕਰਨ ਦਾ ਸਭ ਤੋਂ ਆਸਾਨ ਤਰੀਕਾ ਹੈ ਹਰ PR ਨੂੰ ਇੱਕ ਛੋਟੀ ਯੂਜ਼ਰ-ਸਮਾਰਥ ਕਹਾਣੀ ਮੰਨਣਾ। ਜੇ ਕਿਸੇ ਵਿਅਕਤੀ ਬਾਹਰਲੇ ਤੁਸੀਂ PR ਸਿਰਲੇਖ ਨੂੰ ਪੜ੍ਹ ਕੇ ਸਮਝ ਸਕਦੇ ਹੋ ਕਿ ਕੀ ਬਦਲਿਆ, ਤਾਂ ਤੁਸੀਂ ਅਕਸਰ ਮੰਤਰੀ ਰਾਹ 'ਤੇ ਹੋ।
PR ਸਿਰਲੇਖ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ। ਇਸਨੂੰ ਇੱਕ ਸਪੱਸ਼ਟ ਵਾਕ ਵਿੱਚ ਲਿਖੋ, ਜੋ ਨਤੀਜੇ 'ਤੇ ਕੇਂਦਰਿਤ ਹੋਵੇ, ਨਾ ਕਿ ਇੰਪਲੀਮੈਂਟੇਸ਼ਨ 'ਤੇ। ਤੁਲਨਾ ਕਰੋ “Add caching layer to search” ਨਾਲ “Search results load faster.” ਦੂਜਾ ਸਿੱਧਾ ਚੈਂਜਲੌਗ ਵਿੱਚ ਨਕਲ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।
PR ਵਰਣਨ ਛੋਟਾ ਰੱਖੋ (2 ਤੋਂ 5 ਲਾਈਨਾਂ), ਪਰ ਹਰ ਲਾਈਨ ਦਾ ਇੱਕ ਕੰਮ ਹੋਵੇ:
ਟੈਗ ਬਾਅਦ ਵਿੱਚ ਛਾਂਟਣ ਵਿੱਚ ਮਦਦ ਕਰਦੇ ਹਨ। ਇੱਕਠਾ ਬ੍ਰੈਕਟ ਵਰਗੇ [UI], [API], [Billing], [Performance] ਵਰਤੋ। ਇੱਕ ਜਾਂ ਦੋ ਟੈਗ ਕਾਫੀ ਹਨ। ਬਹੁਤ ਜ਼ਿਆਦਾ ਟੈਗ ਸ਼ੋਰ ਬਣ ਜਾਂਦੇ ਹਨ।
ਹਰ PR ਵਿੱਚ ਇੱਕ “User impact” ਲਾਈਨ ਜੋੜो ਜੋ ਚੈਂਜਲੌਗ ਵਾਂਗ ਪੜ੍ਹੇ। ਉਦਾਹਰਨ: “Admins can now export invoices as CSV.” ਇਹ ਇਕ ਲਾਈਨ ਬਹੁਤ ਕੀਮਤੀ ਹੁੰਦੀ ਹੈ ਜਦ ਤੁਸੀਂ ਤਣਾਅ ਵਿੱਚ ਅਪਡੇਟ ਸਗ੍ਰਹਿਤ ਕਰ ਰਹੇ ਹੋ।
ਜਦੋਂ UI ਬਦਲਿਆ ਹੋਵੇ ਤਬ ਹੀ ਸਕ੍ਰੀਨਸ਼ਾਟ PR ਵਰਣਨ ਵਿੱਚ ਰੱਖੋ। ਇੱਕ ਪਹਿਲਾਂ ਅਤੇ ਇੱਕ ਬਾਅਦ ਵਾਲੀ ਤਸਵੀਰ ਲਓ, ਬਹੁਤ ਜ਼ਿਆਦਾ ਕੱਟ ਕੇ ਉਦੋਂ ਜਾਣਕਾਰੀ ਵਾਲੇ ਖੇਤਰ ਨੂੰ ਦਿਖਾਓ। ਜੇ ਕੋਈ ਵਿਜ਼ੂਅਲ ਬਦਲਾਅ ਨਹੀਂ, ਤਾਂ ਸਕ੍ਰੀਨਸ਼ਾਟ ਛੱਡ ਦਿਓ ਅਤੇ ਇੱਕ ਵਾਧੂ ਸਫ਼ ਕੌਣਟੈਕਸਟ ਲਿਖੋ।
ਇੱਥੇ ਇੱਕ ਸਧਾਰਨ PR ਵਰਣਨ ਟੈਂਪਲੇਟ ਹੈ ਜੋ ਤੁਸੀਂ ਆਪਣੀ ਟੈਮਪਲੇਟ ਵਿੱਚ ਪੇਸਟ ਕਰ ਸਕਦੇ ਹੋ:
[UI] Faster search results
Intent: Reduce wait time on the search page.
User impact: Everyone sees results in under 1 second for common queries.
Edge cases: Empty search now shows “Try a different keyword”.
ਸਕ੍ਰੀਨਸ਼ਾਟ ਲਿਖਣ ਵਿੱਚ ਘੰਟਿਆਂ ਦੀ ਬਚਤ ਕਰ ਸਕਦੇ ਹਨ ਜੇ ਉਹ ਲੱਭਣ ਵਿੱਚ ਆਸਾਨ ਅਤੇ ਸਮਝਣ ਵਿੱਚ ਸੌਖੇ ਹੋਣ। “Screenshot 12” ਵਰਗੇ ਰੇਂਡਮ ਇਮੇਜਾਂ ਦਾ ਢੇਰ ਬਾਅਦ ਵਿੱਚ ਬਿਜੀਵਰਕ ਬਣ ਜਾਂਦਾ ਹੈ।
ਸ਼ੁਰੂ ਕਰੋ ਇੱਕ ਸਧਾਰਨ ਨਾਂਕਰਨ ਪੈਟਰਨ ਨਾਲ ਤਾਂ ਜੋ ਤੁਸੀਂ ਬਾਅਦ ਵਿੱਚ ਫ਼ਿਲਟਰ ਕਰ ਸਕੋ। ਇੱਕ ਵਿਕਲਪ ਹੈ YYYY-MM-DD_area_feature_state। ਉਦਾਹਰਨ: 2026-01-14_billing_invoices_empty.png। ਜਦ ਕੋਈ ਪੁੱਛੇ, “ਅਸੀ ਕਦੋਂ ਇਸ ਸਕ੍ਰੀਨ ਨੂੰ ਬਦਲਿਆ?”, ਤੁਸੀਂ ਸਕਿੰਟਾਂ ਵਿੱਚ ਜਵਾਬ ਦੇ ਸਕਦੇ ਹੋ।
ਉਹ ਸਟੇਟ ਕੈਪਚਰ ਕਰੋ ਜੋ ਕਹਾਣੀ ਦੱਸਦੀ ਹੈ। “ਹੈਪੀ ਪਾਥ” ਹਮੇਸ਼ਾਂ ਸਭ ਤੋਂ ਮਦਦਗਾਰ ਨਹੀਂ ਹੁੰਦਾ। ਜੇ ਰਿਲੀਜ਼ ਵਿਹਾਰ ਬਦਲਦੀ ਹੈ ਤਾਂ ਉਸ ਪਲ ਨੂੰ ਦਿਖਾਓ ਜਿੱਥੇ ਯੂਜ਼ਰ ਇਹ ਨੋਟਿਸ ਕਰੇਗਾ।
ਹਰੇਕ ਬਦਲਾਅ ਲਈ 1 ਤੋਂ 3 ਸਕ੍ਰੀਨਸ਼ਾਟ ਲਛੋ। ਸਭ ਤੋਂ ਵਰਤੇ ਜਾਣ ਵਾਲੇ:
ਐਨੋਟੇਸ਼ਨ ਹਲਕੀ ਰੱਖੋ। ਜੇ ਸਕ੍ਰੀਨਸ਼ਾਟ ਨੂੰ ਮਦਦ ਦੀ ਲੋੜ ਹੈ ਤਾਂ ਇੱਕ ਤੀਰ ਜਾਂ ਇੱਕ ਹਾਈਲਾਈਟ ਜੋੜੋ। ਇਮੇਜ 'ਤੇ ਪੈਰਾ ਨਾ ਪਾਓ। ਵਿਆਖਿਆ PR ਵਰਣਨ ਵਿੱਚ ਰੱਖੋ, ਜਿੱਥੇ ਇਹ ਚੈਂਜਲੌਗ ਵਿੱਚ ਦੁਬਾਰਾ ਵਰਤੀ ਜਾ ਸਕਦੀ ਹੈ।
ਸਕ੍ਰੀਨਸ਼ਾਟ ਕਿੱਥੇ ਰੱਖਦੇ ਹੋ ਇਹ ਵੀ ਉਹਨਾ ਦੇ ਵਰਗੀ ਹੀ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਉਹਨਾਂ ਨੂੰ PR ਦੇ ਨਾਲ (ਜਾਂ ਇੱਕ ਸਾਂਝੇ ਫੋਲਡਰ ਵਿੱਚ) ਸੇਵ ਕਰੋ ਅਤੇ ਫਾਇਲ ਨਾਂ ਜਾਂ ਕੈਪਸ਼ਨ ਵਿੱਚ PR ID ਰੱਖੋ। ਉਦਾਹਰਨ: “PR-1842: updated checkout error message.”
ਇੱਕ ਛੋਟੀ ਆਦਤ ਜੋ ਫਾਇਦਾ ਦਿੰਦੀ ਹੈ: ਜਦ ਤੁਸੀਂ UI ਟੈਕਸਟ, ਫੌਂਟਿੰਗ ਜਾਂ ਕਾਂਟ੍ਰਾਸਟ ਬਦਲਦੇ ਹੋ, ਇੱਕ ਇੱਕ-ਲਾਈਨ ਨੋਟ ਜੋੜੋ ਜਿਵੇਂ “Improved button contrast for readability.” ਉਹ ਲਾਈਨ ਅਕਸਰ ਬਿਨਾਂ ਵਾਧੂ ਸੋਧ ਦੇ ਇੱਕ ਸਾਫ ਉਪਭੋਗਤਾ ਨੋਟ ਬਣ ਜਾਂਦੀ ਹੈ।
ਤੁਹਾਨੂੰ ਭਰਪੂਰ ਸਿਸਟਮ ਦੀ ਲੋੜ ਨਹੀਂ — ਕੇਵਲ ਇੱਕ ਛੋਟੀ ਆਦਤ ਦੀ ਲੋੜ ਹੈ: ਹਰ ਮਰਜ ਕੀਤੇ PR ਵਿੱਚ ਇੱਕ ਛੋਟਾ ਯੂਜ਼ਰ-ਸਮਝਣ ਯੋਗ ਨੋਟ ਹੋਵੇ, ਅਤੇ ਹਰ UI ਬਦਲਾਅ ਨਾਲ ਇੱਕ ਉਸਨੂੰ ਮਿਲਦਾ ਹੋਇਆ ਸਕ੍ਰੀਨਸ਼ਾਟ ਹੋਵੇ।
ਇੱਕ ਰਿਲੀਜ਼ ਵਿੰਡੋ ਚੁਣੋ (ਉਦਾਹਰਨ ਲਈ, ਸੋਮਵਾਰ ਤੋਂ ਸ਼ੁੱਕਰਵਾਰ)। ਉਸ ਵਿੰਡੋ ਦੌਰਾਨ ਮਰਜ ਕੀਤੇ PR ਸਿਰਲੇਖ ਅਤੇ ਵਰਣਨਾਂ ਇੱਕ ਡ੍ਰਾਫਟ ਡੋਕਯੂਮੈਂਟ ਵਿੱਚ ਖਿੱਚੋ। ਜੇ ਕਿਸੇ PR ਵਿੱਚ ਸਪੱਸ਼ਟ ਵਰਣਨ ਨਹੀਂ ਹੈ, ਤਾਂ ਲੇਖਕ ਨੂੰ ਪੁੱਛੋ ਕਿ ਹਾਲੇ ਹੀ ਇੱਕ ਲਾਈਨ ਜੋੜੇ।
UI ਬਦਲਾਅ ਵਾਲੇ PRs ਨੂੰ ਸਕ੍ਰੀਨਸ਼ਾਟ ਮਿਲਾਓ। ਹਰ ਵੇਜ਼ੀਬਲ ਬਦਲਾਅ ਲਈ ਇੱਕ ਸਕ੍ਰੀਨਸ਼ਾਟ ਆਮ ਤੌਰ 'ਤੇ ਕਾਫੀ ਹੁੰਦਾ ਹੈ। ਉਹਨਾਂ ਨੂੰ ਐਸੇ ਲੇਬਲ ਕਰੋ ਕਿ ਇਹ ਸਪੱਸ਼ਟ ਹੋ ਜਾਵੇ ਕਿ ਉਹ ਕੀ ਦਿਖਾ ਰਹੇ ਹਨ (ਪਹਿਲਾਂ/ਬਾਦ ਸੁਖਿਆਦਾਇਕ ਹੁੰਦਾ ਹੈ ਜਦ ਫਰਕ ਸੁੱਖਣਾ ਹੋਵੇ)।
ਫਿਰ ਇੱਕ ਤੇਜ਼ ਕਲੀਨਅਪ ਪਾਸ ਕਰੋ:
ਅੰਤ ਵਿੱਚ ਇੱਕ ਤੇਜ਼ ਸਮੀਖਿਆ ਕਰੋ। ਡ੍ਰਾਫਟ ਸਹਾਇਤਾ ਜਾਂ ਪ੍ਰੋਡਕਟ ਨਾਲ ਸਾਂਝਾ ਕਰੋ ਅਤੇ ਇੱਕ ਸਵਾਲ ਪੁੱਛੋ: “ਕੀ ਇੱਕ ਗਾਹਕ ਸਮਝ ਪਾਵੇਗਾ ਕਿ ਕੀ ਬਦਲਿਆ ਅਤੇ ਕਿਉਂ ਇਹ ਮੈਟਰ ਕਰਦਾ ਹੈ?” ਜੇ ਜਵਾਬ ‘ਨਹੀਂ’ ਹੈ, ਤਾਂ ਸ਼ਬਦ ਸਧਾਰੋ ਜਾਂ ਇੱਕ ਛੋਟਾ ਸੰਦਰਭ ਜੋੜੋ।
ਉਦਾਹਰਨ ਵਜੋਂ, “Refactored permissions middleware” ਦੀ ਜਗ੍ਹਾ ਲਿਖੋ “You can now manage team roles from the Settings page.”
ਕਮਿਟ ਸੁਨੇਹੇ, PR ਨੋਟਸ, ਅਤੇ ਸਕ੍ਰੀਨਸ਼ਾਟਾਂ ਵਗੈਰਾ ਟੀਮਮੈਟਾਂ ਲਈ ਲਿਖੇ ਜਾਂਦੇ ਹਨ। ਰਿਲੀਜ਼ ਨੋਟਸ ਯੂਜ਼ਰਾਂ ਲਈ ਲਿਖੇ ਜਾਂਦੇ ਹਨ। ਕੰਮ ਦੀ ਨਕਲ-ਪੇਸਟ ਨਹੀਂ, ਇਸਨੂੰ ਅਨੁਵਾਦ ਕਰੋ।
ਕੁਝ ਰੂਲ ਹਰ ਐਂਟਰੀ ਨੂੰ ਸਪਸ਼ਟ ਰੱਖਦੇ ਹਨ:
ਇਕਸਾਰਤਾ ਬਹੁਤ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਇੱਕ ਟੈਂਸ ਚੁਣੋ (ਜਿਆਦਾਤਰ ਟੀਮਾਂ ਭੂਤਕਾਲ ਵਰਤਦੀਆਂ ਹਨ: “Fixed,” “Improved,” “Added”) ਅਤੇ ਉਸ ਤੇ ਟਿਕੋ। ਹਰ ਵਾਰੀ ਇੱਕੋ ਹੀ ਕੈਪਟਲਾਈਜੇਸ਼ਨ ਨਿਯਮ ਵਰਤੋਂ। ਜੇ ਤੁਸੀਂ ਫੀਚਰਾਂ ਨੂੰ ਨਾਮ ਦਿੰਦੇ ਹੋ, ਤਾਂ ਇੱਕ ਨਿਯਮ ਦੀ ਪਾਲਣਾ ਕਰੋ, ਜਿਵੇਂ “Feature name (area)” ਜਿਵੇਂ “Saved views (Reports)।” ਇਹ ਛੋਟੇ ਨਿਯਮ ਚੈਂਜਲੌਗ ਨੂੰ ਗਦਬਦ ਤੋਂ ਬਚਾਉਂਦੇ ਹਨ।
ਜਦੋਂ ਕੁਝ ਯੂਜ਼ਰ ਨੂੰ ਰੋਕੇਗਾ, ਤਾਂ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਦੱਸੋ ਅਤੇ ਅਗਲਾ ਕਦਮ ਦਿਖਾਓ। ਤਕਨੀਕੀ ਕਾਰਨ ਛੱਡੋ।
ਉਦਾਹਰਨ: “API keys created before Jan 10 will stop working. Create a new key in Settings - API keys.”
ਝੜਪ-ਅਨੁਭਵ ਹੋਣ ਦੀ ਸੰਭਾਵਨਾ ਹੋਵੇ ਤਾਂ ਹੀ "Known issues" ਸੈਕਸ਼ਨ ਸ਼ਾਮਲ ਕਰੋ। ਛੋਟਾ ਰੱਖੋ ਅਤੇ ਜੇ ਕੋਈ ਵਰਕਅਰਾਉਂਡ ਹੈ ਤਾਂ ਉਹ ਦਿਓ।
ਉਦਾਹਰਨ: “Known issue: CSV export may time out on very large reports. Workaround: export by date range.”
ਸਕ੍ਰੀਨਸ਼ਾਟਸ ਨੂੰ ਉਹ ਸਥਾਨ ਦਿਉ ਜਿਥੇ ਉਹ ਸਹਾਇਕ ਹਨ। ਜੇ ਬਦਲਾਅ ਨਿੱਕਾ ਹੈ (ਸਪੇਸਿੰਗ, ਰੰਗ, ਛੋਟੀ ਕਾਪੀ ਸੋਧ) ਜਾਂ UI ਅਗਲੇ ਰਿਲੀਜ਼ ਤੱਕ ਬਦਲ ਸਕਦਾ ਹੈ, ਤਾਂ ਸਕ੍ਰੀਨਸ਼ਾਟ ਅੰਦਰੂਨੀ ਰੱਖੋ।
ਜ਼ਿਆਦਾਤਰ ਰਿਲੀਜ਼ ਨੋਟ ਦਰਦ ਉਹ ਸਮੇਂ ਆ ਜਾਂਦਾ ਹੈ ਜਦ ਇੱਕ ਹਫਤਾ ਬਾਅਦ ਕੋਈ ਪੁੱਛਦਾ ਹੈ, “ਕੀ ਇਹ ਬਦਲਾਅ ਇਰਾਦਤ ਨਾਲ ਸੀ?” ਅਤੇ ਤੁਹਾਨੂੰ PRs, ਸਕ੍ਰੀਨਸ਼ਾਟਸ ਅਤੇ ਚੈਟ ਥ੍ਰੈਡਾਂ ਵਿੱਚ ਖੋਜ ਕਰਨੀ ਪੈਂਦੀ ਹੈ। ਜੇ ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਹੋ ਕਿ ਆਟੋਮੈਟਿਕ ਰਿਲੀਜ਼ ਨੋਟਸ ਲੰਬੇ ਸਮੇਂ ਤੱਕ ਲਾਭਦਾਇਕ ਰਹਿਣ, ਤਾਂ ਉਹ ਫੰਦਾ ਜਿਹੜੇ ਨੋਟਸ ਨੂੰ ਪੜ੍ਹਨ ਯੋਗ ਅਤੇ ਭਰੋਸੇਯੋਗ ਨਹੀਂ ਬਣਾਉਂਦੇ, ਉਨਾਂ ਤੋਂ ਬਚੋ।
ਇਹ ਰੂਪ-ਰੇਖਾ ਅਕਸਰ ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਰੀਵਰਕ ਪੈਦਾ ਕਰਦੀ ਹੈ:
ਛੋਟੇ UI ਬਦਲਾਅ ਅਕਸਰ ਛੱਡ ਦਿੱਤੇ ਜਾਂਦੇ ਹਨ। ਇਕ ਨਾਮ-ਬਦਲਾ ਬਟਨ, ਇੱਕ ਮੈניੂ ਆਈਟਮ ਦਾ ਸਥਾਨ ਬਦਲਣਾ, ਜਾਂ ਨਵਾਂ ਖਾਲੀ ਸਟੇਟ ਯੂਜ਼ਰਾਂ ਨੂੰ ਪਿੱਛੇ ਮੋੜ ਸਕਦੇ ਹਨ। ਜੇ ਸਕ੍ਰੀਨਸ਼ਾਟ ਬਦਲੇ, ਤਾਂ ਉਸਨੂੰ ਸੰਖੇਪ ਵਿੱਚ ਜ਼ਿਕਰ ਕਰੋ। ਇੱਕ ਸਧਾਰਨ ਲਾਈਨ ਜਿਵੇਂ “Export button ਟੇਬਲ ਦੇ ਟੌਪ-ਰਾਈਟ ਵਿੱਚ ਹੋ ਗਿਆ” ਝੜਪ-ਵਾਰ ਬਹੁਤ ਸਵਾਲ ਬਚਾ ਸਕਦੀ ਹੈ।
ਇੱਥੇ ਇੱਕ ਛੋਟਾ ਉਦਾਹਰਨ ਹੈ। ਤੁਸੀਂ ਨਵਾਂ ਬਿਲਿੰਗ ਪੇਜ ਲੇਆਊਟ ਸ਼ਿਪ ਕਰਦੇ ਹੋ ਅਤੇ ਨਾਲ ਹੀ ਇਨਵੌਇਸਾਂ ਨੂੰ ਸੰਪਾਦਨ ਕਰਨ ਦੀ ਅਧਿਕਾਰਤਾ ਕੱਤੜ ਕਰਦੇ ਹੋ। ਜੇ ਤੁਸੀਂ ਸਿਰਫ਼ “Improved billing page” ਹੀ ਲਿਖਦੇ ਹੋ ਤਾਂ ਐਡਮਿਨ ਸਮਝਣਗੇ ਕਿ ਹੋਰ ਕੁਝ ਨਹੀਂ ਬਦਲਾ। ਇੱਕ ਵਧੀਆ ਨੋਟ ਉਨ੍ਹਾਂ ਨੂੰ ਵੱਖ-ਵੱਖ ਰੇਖਾਂ ਵਿੱਚ ਵੰਡੇ: ਇੱਕ ਲੇਆਊਟ ਬਦਲਾਅ ਲਈ, ਦੂਜਾ ਭੂਮਿਕਾ ਬਦਲਾਅ ਲਈ, ਭੂਮਿਕਾ ਦਾ ਨਾਮ ਦੇ ਕੇ।
ਚੰਗੀ ਰਿਲੀਜ਼ ਨੋਟਜ਼ ਲੰਬੀਆਂ ਨਹੀਂ ਹੁੰਦੀਆਂ — ਉਹ ਸਪੱਸ਼ਟ ਹੁੰਦੀਆਂ ਹਨ ਅਤੇ ਵੱਡੇ ਸਮੇਂ ਤੱਕ ਅਰਥਪੂਰਨ ਰਹਿੰਦੀਆਂ ਹਨ।
ਇੱਕ ਚੰਗੀ ਰਿਲੀਜ਼ ਨੋਟ ਤਿੰਨ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਤੇਜ਼ੀ ਨਾਲ ਦਿੰਦੀ ਹੈ: ਕੀ ਬਦਲਿਆ, ਕਿੱਥੇ ਵੇਖਣਾ ਹੈ, ਅਤੇ ਕਿਸ ਨੂੰ ਇਹ ਮੈਟਰ ਕਰਦਾ ਹੈ। ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਆਖਰੀ ਪਾਸ ਕਰੋ।
ਹਰ ਆਈਟਮ ਨੂੰ ਉਪਭੋਗਤਾ ਵਾਂਗ ਪੜ੍ਹੋ, ਨਾ ਕਿ ਬਿਲਡਰ ਵਾਂਗ। ਜੇ ਤੁਹਾਨੂੰ ਅਰਥ ਲਗਾਉਣ ਲਈ ਅਨੁਮਾਨ ਲਗਾਉਣਾ ਪੈ ਰਿਹਾ ਹੈ, ਤਾਂ ਦੁਬਾਰਾ ਲਿਖੋ।
ਚੈੱਕਲਿਸਟ ਤੋਂ ਬਾਅਦ, ਇੱਕ ਛੋਟੀ “ਅਨੁਵਾਦ” ਪੜ੍ਹੋ। ਅੰਦਰੂਨੀ ਸ਼ਬਦ (ਟਿਕਟ ID, ਕੰਪੋਨੈਂਟ ਨਾਮ, ਫੀਚਰ ਫਲੈਗ) ਨੂੰ ਸਾਧਾਰਨ ਉਪਕාරਕ ਸ਼ਬਦਾਂ ਨਾਲ ਬਦਲੋ। ਜੇ ਕੋਈ ਫੀਚਰ ਰੋਲਆਊਟ ਪਿੱਛੇ ਹੈ ਜਾਂ ਕੇਵਲ ਕੁਝ ਟੀਅਰਾਂ ਲਈ ਉਪਲਬਧ ਹੈ, ਤਾਂ ਇਸ ਨੂੰ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਦੱਸੋ।
ਇੱਕ ਵਿਅਕਤੀ ਜੋ ਇੰਜੀਨੀਅਰਿੰਗ ਤੋਂ ਬਾਹਰ ਹੈ ਉਸ ਨੂੰ ਪੜ੍ਹਨ ਲਈ ਦਿਓ। ਇਹ ਕੋਈ ਫਾਊਂਡਰ, ਸਹਾਇਤਾ, ਸੇਲਜ਼ ਜਾਂ ਦੋਸਤ ਹੋ ਸਕਦਾ ਹੈ। ਜੇ ਉਹ 10 ਸਕਿੰਟ ਵਿੱਚ “ਕੀ ਬਦਲਿਆ?” ਦਾ ਉੱਤਰ ਨਹੀਂ ਦੇ ਸਕਦਾ, ਤਾਂ ਲਿਖਤ ਹਜੇ PR ਬਹੁਤ ਨਜ਼ਦੀਕ ਹੈ।
ਉਦਾਹਰਨ: “Improved settings modal state handling” ਬਨ ਜਾਂਦਾ ਹੈ “Settings ਹੁਣ ਟੈਬ ਬਦਲਣ ਤੋਂ ਬਾਅਦ ਭਰੋਸੇਯੋਗ ਤਰੀਕੇ ਨਾਲ ਸੇਵ ਹੁੰਦੇ ਹਨ।”
ਇੱਕ ਛੋਟੀ ਟੀਮ ਹਫਤੇ ਵਿੱਚ 12 PRs ਸ਼ਿਪ ਕਰਦੀ ਹੈ: 4 UI ਟਵੀਕਸ, 2 ਬੱਗ ਫਿਕਸ, ਅਤੇ ਬਾਕੀ ਛੋਟੇ ਰੀਫੈਕਟਰ ਅਤੇ ਟੈਸਟ। ਉਹ ਆਟੋਮੈਟਿਕ ਰਿਲੀਜ਼ ਨੋਟਸ ਚਾਹੁੰਦੇ ਹਨ, ਪਰ ਉਹ ਵੀ ਚਾਹੁੰਦੇ ਹਨ ਕਿ ਇਹ ਮਨੁੱਖੀ ਲਿਖੇ ਵਰਗੇ ਪੜ੍ਹਨ।
ਉਸ ਦੀ ਬਜਾਏ ਕਿ ਸ਼ੁੱਕਰਵਾਰ ਤੱਕ ਇੰਤਜ਼ਾਰ ਕਰਨਾ, ਉਹ ਕੰਮ ਕਰਦੇ ਸਮੇਂ ਇਨਪੁਟ ਇਕੱਠੇ ਕਰਦੇ ਹਨ। ਹਰ PR ਵਿੱਚ ਇੱਕ “ਯੂਜ਼ਰ-ਫੇਸਿੰਗ ਨੋਟ” ਲਾਈਨ ਹੋਂਦੀ ਹੈ ਅਤੇ ਜੇ UI ਬਦਲਿਆ ਤਾਂ ਇੱਕ ਪਹਿਲਾਂ/ਬਾਦ ਸਕ੍ਰੀਨਸ਼ਾਟ। ਸਕ੍ਰੀਨਸ਼ਾਟ PR ਨੋਟਸ ਦੇ ਕੋਲ ਰਹਿੰਦੇ ਹਨ (ਹਰ ਵਾਰੀ ਇਕੋ ਜਗ੍ਹਾ), ਤਾਂ ਕੋਈ ਚੈਟ ਥ੍ਰੈਡ ਖੋਜਣ ਦੀ ਜ਼ਰੂਰਤ ਨਹੀਂ ਰਹਿੰਦੀ।
ਸ਼ੁੱਕਰਵਾਰ ਨੂੰ ਇੱਕ ਵਿਅਕਤੀ PR ਨੋਟਸ ਨੂੰ ਸਕੈਨ ਕਰਦਾ ਹੈ ਅਤੇ ਸਮਾਨ ਬਦਲਾਅ ਗਰੁੱਪ ਕਰਦਾ ਹੈ। 4 ਛੋਟੀ UI ਟਵੀਕਸ ਇੱਕ ਨੋਟ ਬਣ ਜਾਂਦੀਆਂ ਅਤੇ 3 ਅੰਦਰੂਨੀ ਰੀਫੈਕਟਰ ਹਟ ਜਾਂਦੇ ਹਨ ਕਿਉਂਕਿ ਯੂਜ਼ਰਾਂ ਨੂੰ ਉਨ੍ਹਾਂ ਦੀ ਪਰਵਾਹ ਨਹੀਂ।
ਇੱਥੇ ਪ੍ਰਕਾਸ਼ਿਤ ਹਫਤਾਵਾਰੀ ਚੈਂਜਲੌਗ ਦਾ ਉਦਾਹਰਨ ਹੈ:
ਜਿੱਥੇ ਸੰਪਾਦਨ ਕਰਕੇ ਟੀਮ ਵਾਪਸ ਵਕਤ ਬਚਾਂਦੀ ਹੈ। PR ਨੋਟ “Refactor billing-summary component, rename prop, update tests” ਬਨ ਜਾਂਦਾ ਹੈ “Improved the Billing page layout and labels for clearer totals.” “Fix N+1 query in projects list” ਬਨ ਜਾਂਦਾ ਹੈ “Improved dashboard load time when you have many projects.”
ਸਕ੍ਰੀਨਸ਼ਾਟਾਂ ਨਾਲ ਭੁਲੇਖਾ ਘਟਦਾ ਹੈ ਜਦ ਸ਼ਬਦ ਬਦਲ ਜਾਂਦੇ ਹਨ। ਜੇ ਬਟਨ ਲੇਬਲ “Archive” ਤੋਂ “Deactivate” ਹੋ ਗਿਆ, ਤਸਵੀਰ ਸਪੱਸ਼ਟ ਕਰਦੀ ਹੈ ਕਿ ਯੂਜ਼ਰ ਨੂੰ ਕੀ ਨਜ਼ਰ ਆਏਗਾ ਅਤੇ ਸਪੋਰਟ ਨੂੰ ਅਨੁਮਾਨ ਨਹੀਂ ਲਗਾਉਣਾ ਪੈਂਦਾ ਕਿ ਨੋਟ ਕਿਸ ਸਕ੍ਰੀਨ ਨਾਲ ਸਬੰਧਿਤ ਹੈ।
“ਅਸੀਂ ਇਕ ਵਾਰੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ” ਅਤੇ ਨੋਟਸ ਜੋ ਟਿਕਦੇ ਹਨ ਵਿਚਕਾਰ ਦਾ ਸਭ ਤੋਂ ਵੱਡਾ ਫਰਕ ਇੱਕ ਛੋਟੀ ਰੁਟੀਨ ਹੈ। ਹਰ ਰਿਲੀਜ਼ ਵਿੰਡੋ ਲਈ ਇੱਕ ਵਿਅਕਤੀ ਚੁਣੋ ਅਤੇ ਉਸਨੂੰ ਨੀਰਧਾਰਿਤ 30 ਮਿੰਟ ਦਾ ਸਮਾਂ ਦਿਓ। ਜਦ ਇਸਦਾ ਮਾਲਿਕ ਅਤੇ ਸਮਾਂ ਨਿਯਤ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਇਹ ਸਭ ਦਾ ਮੁੱਦਾ ਰਹਿਣ ਤੋਂ ਬਚ ਜਾਂਦਾ ਹੈ।
ਆਪਣਾ PR ਟੈਂਪਲੇਟ ਅਤੇ ਸਕ੍ਰੀਨਸ਼ਾਟ ਨਿਯਮ ਨਾਰਮਲ ਕੰਮ ਦਾ ਹਿੱਸਾ ਬਣਾਓ, ਨਾ ਕਿ ਕੋਈ ਵਿਸ਼ੇਸ਼ ਪ੍ਰਕਿਰਿਆ। ਜੇ ਕਿਸੇ PR ਵਿੱਚ ਯੂਜ਼ਰ-ਪ੍ਰਭਾਵ ਲਾਈਨ ਜਾਂ ਪਹਿਲਾਂ/ਬਾਦ ਸਕ੍ਰੀਨਸ਼ਾਟ ਨਹੀਂ ਹਨ, ਤਾਂ ਇਹ “ਵਾਧੂ ਪਾਲਿਸ਼” ਨਹੀਂ — ਇਹ ਜਾਣਕਾਰੀ ਗ਼ਾਇਬ ਹੈ।
ਇੱਕ ਹਲਕਾ ਡਰਾਫਟ ਡਾਕ ਇੱਕ ਆਸਾਨ ਆਦਤ-ਬਣਾਉਣ ਵਾਲੀ ਚੀਜ਼ ਹੈ। ਮੌਜੂਦਾ ਰਿਲੀਜ਼ ਲਈ ਇੱਕ ਚੱਲਦਾ ਡਰਾਫਟ ਰੱਖੋ ਅਤੇ ਜੈਸੇ-ਜੈਸੇ PRs ਮਰਜ ਹੋਣ, ਇਸਨੂੰ ਅਪਡੇਟ ਕਰੋ। ਰਿਲੀਜ਼ ਦਿਵਸ ਸੰਪਾਦਨ ਬਣ ਜਾਂਦਾ ਹੈ, ਨਕਲ ਲਿਖਣ ਦੀ ਨਸਲ ਨਹੀਂ।
ਇੱਕ ਸਧਾਰਨ ਰਿਧਮ ਜੋ ਚੰਗਾ ਕੰਮ ਕਰਦਾ ਹੈ:
ਜੇ ਫਾਰਮੈਟਿੰਗ ਫਿਰ ਵੀ ਜ਼ਿਆਦਾ ਸਮਾਂ ਲੈਂਦੀ ਹੈ, ਤਾਂ ਇੱਕ ਛੋਟਾ ਅੰਦਰੂਨੀ ਡ੍ਰਾਫਟ ਜਨਰੇਟਰ ਬਣਾਓ। ਇਹ PR ਟੈਕਸਟ ਨੂੰ ਪੜ੍ਹ ਸਕਦਾ, ਤੁਹਾਡੇ ਟੈਂਪਲੇਟ ਹੈਡਿੰਗ ਲਗਾ ਸਕਦਾ, ਅਤੇ ਇੱਕ ਸਾਫ ਡਰਾਫਟ ਆਉਟਪੁੱਟ ਕਰ ਸਕਦਾ ਹੈ ਜੋ ਸਿਰਫ਼ ਹਲਕੀ ਸੋਧ ਮੰਗਦਾ ਹੈ। ਛੋਟੇ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ: ਹੈਡਿੰਗ ਦੁਆਰਾ ਗਰੂਪ ਕਰਨਾ ਅਤੇ ਸਕ੍ਰੀਨਸ਼ਾਟ ਕੈਪਸ਼ਨਾਂ ਨੂੰ ਖਿੱਚਣਾ ਅਕਸਰ ਕਾਫੀ ਹੁੰਦਾ ਹੈ।
ਜੇ ਤੁਸੀਂ ਚੈਟ ਰਾਹੀਂ ਅਜਿਹੇ ਜਨਰੇਟਰ ਦਾ ਪ੍ਰੋਟੋਟਾਈਪ ਬਣਾਉਣਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ Koder.ai (koder.ai) ਇੱਕ ਵਿਕਲਪ ਹੈ। ਤੁਸੀਂ ਪ੍ਰਾਪਟ ਤੇਜ਼ੀ ਨਾਲ ਪ੍ਰੋੰਪਟ ਅਤੇ ਆਉਟਪੁੱਟ ਫਾਰਮੈਟ ਤੇ ਇਟਰੇਟ ਕਰ ਸਕਦੇ ਹੋ, ਫਿਰ ਜਦੋਂ ਤਿਆਰ ਹੋਵੋ, ਸੋਰਸ ਕੋਡ ਐਕਸਪੋਰਟ ਕਰ ਸਕਦੇ ਹੋ।
PR ਸਿਰਲੇਖ ਅਤੇ PR ਵਰਣਨਾਂ ਨੂੰ ਮੁੱਖ ਸਰੋਤ ਵਜੋਂ ਵਰਤੋ, ਕਿਉਂਕਿ ਉਹ ਆਮ ਤੌਰ 'ਤੇ “ਕਿਉਂ” ਅਤੇ ਯੂਜ਼ਰ ਪ੍ਰਭਾਵ ਦੱਸਦੀਆਂ ਹਨ। ਕਮਿਟ ਕੋਡ ਬਦਲਾਵ ਟਰੇਸ ਕਰਨ ਲਈ ਵਧੀਆ ਹੁੰਦੇ ਹਨ, ਪਰ ਉਹ ਅਕਸਰ ਉਸ ਤਰ੍ਹਾਂ ਨਹੀਂ ਲਿਖੇ ਹੁੰਦੇ ਜਿਵੇਂ ਗ੍ਰਾਹਕ ਪੜ੍ਹਨਾ ਚਾਹੁੰਦਾ ਹੈ।
ਸਿਰਲੇਖ ਨੂੰ ਸਾਫ਼ ਭਾਸ਼ਾ ਵਿੱਚ ਲਿਖੋ ਜੋ ਯੂਜ਼ਰ ਦੇ ਨਤੀਜੇ 'ਤੇ ਕੇਂਦਰਿਤ ਹੋਵੇ। ਜੇ ਇਹ ਘੱਟ-ਤੋ-ਘੱਟ ਸੋਧਾਂ ਨਾਲ ਚੈਂਜਲੌਗ ਵਿੱਚ ਨਕਲ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਤਾਂ ਇਹ ਆਪਣਾ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ।
ਛੋਟੀ ਅਤੇ ਇੱਕਸਾਰ ਰੀਤੀ ਰੱਖੋ: ਕੀ ਬਦਲਿਆ, ਕਿਸ ਨੂੰ ਪ੍ਰਭਾਵਤ ਕਰਦਾ ਹੈ, ਅਤੇ ਕਿੱਥੇ ਮਿਲੇਗਾ। ਇਹ ਧੁੰਦਲੇ ਨੋਟਸ ਤੋਂ ਬਚਾਉਂਦਾ ਹੈ ਅਤੇ ਹਰ ਐਂਟਰੀ ਨੂੰ ਬਾਅਦ ਵਿੱਚ ਸਕੈਨ ਕਰਨ ਯੋਗ ਬਣਾਉਂਦਾ ਹੈ।
4 ਤੋਂ 6 ਥੈਲੇ/ਸ਼੍ਰੇਣੀਆਂ ਚੁਣੋ ਜੋ ਉਪਭੋਗਤਿਆਂ ਦੁਆਰਾ ਜਾਣੀਆਂ ਜਾਂਦੀਆਂ ਹਨ, ਜਿਵੇਂ New, Improvements, Fixes, Security, ਅਤੇ Admin. ਹਮੇਸ਼ਾਂ ਇੱਕੋ ਹੀ ਕੀਟੇਗਰੀਆਂ ਰੱਖੋ ਤਾਂ ਜੋ ਫਾਰਮੈਟਿੰਗ ਇਕਸਾਰ ਰਹੇ।
ਜੇਕਰ ਕੋਈ ਯੂਜ਼ਰ ਇਸਨੂੰ ਨੋਟਿਸ ਕਰ ਸਕਦਾ, ਇਸਤੇ ਨਿਰਭਰ ਕਰ ਸਕਦਾ, ਜਾਂ ਖੋਜ ਸਕਦਾ ਹੈ ਤਾਂ ਉਸਨੂੰ ਸ਼ਾਮਲ ਕਰੋ। ਸਿਰਫ਼ ਰੀਫੈਕਟਰ, ਡਿਪੈਂਡੇਸੀ ਬੰਪ, ਅਤੇ ਲੋਗਿੰਗ ਬਦਲਾਵ ਆਮ ਤੌਰ 'ਤੇ ਅੰਦਰੂਨੀ ਚੈਂਜਲੌਗ ਵਿੱਚ ਰਹਿਣਗੇ ਜੇਕਰ ਉਹ ਵਿਹਾਰ ਨਹੀਂ ਬਦਲਦੇ।
ਸਿਰਫ਼ ਉਦੋਂ ਸਕ੍ਰੀਨਸ਼ਾਟ ਜੋ UI ਬਦਲਿਆ ਗਿਆ ਹੋਵੇ ਅਤੇ ਜਿਹੜੇ ਤਸਵੀਰ ਨਾਲ ਗੁੰਝਲ ਦੂਰ ਹੋ ਸਕਦੀ ਹੈ, ਜੋੜੋ — ਜਿਵੇਂ ਕਿ ਬਟਨ ਦਾ ਅਸਥਾਨ ਬਦਲਣਾ, ਲੇਬਲ ਰੀਨੇਮ ਹੋਣਾ ਜਾਂ ਨਵਾਂ ਕਦਮ। ਇੱਕ ਸਾਫ਼ ਤਸਵੀਰ ਜਾਂ ਪਹਿਲਾਂ/ਬਾਦ ਜੋੜਨਾ ਆਮ ਤੌਰ 'ਤੇ ਕਾਫ਼ੀ ਹੁੰਦਾ ਹੈ।
ਇੱਕ ਲਗਾਤਾਰ, ਖੋਜਯੋਗ ਨਾਂਕਰਨ ਰੂਪ ਵਰਤੋ ਜਿਸ ਵਿੱਚ ਤਾਰੀਖ ਅਤੇ ਪ੍ਰੋਡਕਟ ਖੇਤਰ ਸ਼ਾਮਲ ਹੋਵੇ। ਫਾਇਲ ਨਾਂ ਜਾਂ ਕੈਪਸ਼ਨ ਵਿੱਚ PR ID ਰੱਖੋ ਤਾਂ ਕਿ ਬਦਲਾਵ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਟਰੇਸ ਕੀਤਾ ਜਾ ਸਕੇ।
ਪਹਿਲਾਂ ਪ੍ਰਭਾਵ ਦੱਸੋ ਅਤੇ ਯੂਜ਼ਰ ਨੂੰ ਅੱਗੇ ਕੀ ਕਰਨਾ ਹੈ ਬਾਰੇ ਸਪੱਸ਼ਟ ਦਿਸ਼ਾ ਦਿਓ। ਤਕਨੀਕੀ ਕਾਰਣ ਦੀ ਵਰਣਨਾ ਛੱਡੋ। ਜਿਵੇਂ: “Jan 10 ਤੋਂ ਪਹਿਲਾਂ ਬਣਾਈਆਂ ਗਈਆਂ API ਕੁੰਜੀਆਂ ਕੰਮ ਕਰਨਾ ਬੰਦ ਕਰ ਦੇਣਗੀਆਂ। Settings - API keys ਵਿੱਚ ਨਵੀਂ ਕੁੰਜੀ ਬਣਾਓ।”
ਸਿਰਫ਼ ਉਹਨਾਂ ਮਾਮਲਿਆਂ ਨੂੰ ਸ਼ਾਮਲ ਕਰੋ ਜਿਨ੍ਹਾਂ ਨਾਲ ਯੂਜ਼ਰ ਨੂੰ ਸੰਭਵ ਤੌਰ 'ਤੇ ਮੁਕਾਬਲਾ ਕਰਨਾ ਪੈ ਸਕਦਾ ਹੈ, ਅਤੇ ਹਮੇਸ਼ਾਂ ਵਰਕਅਰਾਉਂਡ ਦਿੱਤੀਆਂ ਭਲੇ ਹੋਣ। ਉਦਾਹਰਨ: “ਜਾਣਿਆ ਗਿਆ ਮੁੱਦਾ: ਬਹੁਤ ਵੱਡੀਆਂ ਰਿਪੋਰਟਾਂ 'ਤੇ CSV ਐਕਸਪੋਰਟ ਟਾਈਮਆਉਟ ਹੋ ਸਕਦਾ ਹੈ। ਵਰਕਅਰਾਉਂਡ: ਤਾਰੀਖ ਰੇਂਜ ਅਨੁਸਾਰ ਐਕਸਪੋਰਟ ਕਰੋ।”
ਹਰ ਮਰਜ ਕੀਤੇ PR ਨੂੰ ਇੱਕ ਛੋਟਾ ਯੂਜ਼ਰ-ਫੇਸਿੰਗ ਕਹਾਣੀ ਮੰਨੋ, ਫਿਰ ਨਿਰਧਾਰਤ ਵਿੰਡੋ ਲਈ ਮਰਜ ਕੀਤੇ PR ਨੋਟਸ ਇਕੱਠੇ ਕਰੋ ਅਤੇ ਉਨ੍ਹਾਂ ਨੂੰ ਆਪਣੀਆਂ ਫਿਕਸਤ ਸ਼੍ਰੇਣੀਆਂ ਵਿੱਚ ਗ੍ਰੂਪ ਕਰੋ। ਟੂਲ ਮਦਦ ਕਰ ਸਕਦੇ ਹਨ ਪਰ ਹਲਕਾ ਮਨੁੱਖੀ ਰਿਵਿਊ ਲਾਜ਼ਮੀ ਹੈ ਤਾਂ ਕਿ ਡੁਪਲਿਕੇਟ ਹਟਾਏ ਜਾਣ ਅਤੇ ਭਾਸ਼ਾ ਸਹੀ ਰਹੇ।