05 ਮਾਰਚ 2025·6 ਮਿੰਟ
ਫੀਚਰ ਰਿਕਵੈਸਟ ਵੋਟਿੰਗ ਲਈ ਵੈੱਬ ਐਪ ਕਿਵੇਂ ਬਣਾਈਏ
ਉਪਯੋਗਕਰਤਾ ਫੀਚਰ ਵਿਚਾਰ ਜਮ੍ਹਾਂ ਕਰਨ, ਵੋਟ ਕਰਨ ਅਤੇ ਐਡਮਿਨ ਟ੍ਰਾਇਜੇ ਸਮਰੱਥਾ ਦੇ ਨਾਲ ਇੱਕ ਵੈੱਬ ਐਪ ਯੋਜਨਾ ਬਣਾਓ, ਤਿਆਰ ਕਰੋ ਅਤੇ ਲਾਂਚ ਕਰੋ — ਸਪਸ਼ਟ ਨਿਯਮ, ਸਥਿਤੀਆਂ ਅਤੇ ਰਿਪੋਰਟਿੰਗ ਸਮੇਤ।
ਉਪਯੋਗਕਰਤਾ ਫੀਚਰ ਵਿਚਾਰ ਜਮ੍ਹਾਂ ਕਰਨ, ਵੋਟ ਕਰਨ ਅਤੇ ਐਡਮਿਨ ਟ੍ਰਾਇਜੇ ਸਮਰੱਥਾ ਦੇ ਨਾਲ ਇੱਕ ਵੈੱਬ ਐਪ ਯੋਜਨਾ ਬਣਾਓ, ਤਿਆਰ ਕਰੋ ਅਤੇ ਲਾਂਚ ਕਰੋ — ਸਪਸ਼ਟ ਨਿਯਮ, ਸਥਿਤੀਆਂ ਅਤੇ ਰਿਪੋਰਟਿੰਗ ਸਮੇਤ।
ਸਕਰੀਨ ਡਿਜ਼ਾਇਨ ਜਾਂ ਡੇਟਾਬੇਸ ਚੁਣਨ ਤੋਂ ਪਹਿਲਾਂ ਇਹ ਫੈਸਲਾ ਕਰੋ ਕਿ “ਫੀਚਰ ਰਿਕਵੈਸਟ ਵੋਟਿੰਗ” ਤੁਹਾਡੇ ਪ੍ਰੋਡਕਟ ਟੀਮ ਲਈ ਕੀ ਹਾਸਲ ਕਰਨ ਦੇਖ ਰਹੀ ਹੈ। ਇੱਕ ਵੋਟਿੰਗ ਪੋਰਟਲ ਹੋ ਸਕਦਾ ਹੈ:
ਜੇ ਤੁਸੀਂ ਪ੍ਰਧਾਨ ਉਦੇਸ਼ ਨਹੀਂ ਚੁਣਦੇ, ਤਾਂ ਨਿਯਮ ਅਸਪਸ਼ਟ ਹੋ ਜਾਣਗੇ ਅਤੇ ਡੇਟਾ ਸ਼ੋਰ ਭਰਿਆ ਹੋਵੇਗਾ।
ਦਰਸ਼ਕ ਅਤੇ ਕੀ ਉਹ ਇੱਕੋ ਹੀ ਜਗ੍ਹਾ ਸਾਂਝਾ ਕਰਦੇ ਹਨ, ਇਸ ਬਾਰੇ ਸਪਸ਼ਟ ਹੋਵੋ:
ਘੱਟੋ-ਘੱਟ, ਯੂਜ਼ਰਾਂ ਨੂੰ ਸਮਰੱਥ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ: ਰਿਕਵੈਸਟ ਜਮ੍ਹਾਂ ਕਰਨਾ, ਵੋਟ ਕਰਨਾ, ਟਿੱਪਣੀ, ਅਪਡੇਟ ਫੋਲੋ ਕਰਨਾ, ਅਤੇ ਖੋਜਣਾ।
ਖੋਜ ਉਸ ਤੋਂ ਵੱਧ ਮਹੱਤਵਪੂਰਨ ਹੈ ਜਿਵੇਂ ਦਿਸਦਾ ਹੈ: ਇਹ ਡੁਪਲਿਕੇਟ ਰੋਕਦਾ ਹੈ ਅਤੇ ਪੋਰਟਲ ਨੂੰ ਉਪਯੋਗੀ ਮਹਿਸੂਸ ਕਰਵਾਉਂਦਾ ਹੈ ਜਦੋਂ ਕੋਈ ਨਵੀਂ ਪੋਸਟ ਨਹੀਂ ਕਰ ਰਿਹਾ।
ਤੁਹਾਡੀ ਪ੍ਰੋਡਕਟ ਟੀਮ ਨੂੰ ਇੱਕ ਹਲਕਾ ਫੁੱਲਕਾ ਟ੍ਰਾਇਜੇ ਲੂਪ ਚਾਹੀਦਾ ਹੈ:
ਜੇ ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਕਦਮ ਐਪ ਦੇ ਬਾਹਰ ਹੱਥੋਂ-ਹੱਥ ਹੋਵੇ, ਤਾਂ ਸਿਸਟਮ ਅਪ-ਟੂ-ਡੇਟ ਨਹੀਂ ਰਹੇਗਾ।
ਮਾਪ ਯੋਗ ਨਤੀਜੇ ਚੁਣੋ ਜਿਵੇਂ:
ਇਹ ਲਕੜੀਆਂ ਬਾਅਦ ਦੇ ਫੈਸਲਿਆਂ ਨੂੰ ਚਲਾਉਣਗੀਆਂ — ਵੋਟਿੰਗ ਨਿਯਮਾਂ ਤੋਂ ਲੈ ਕੇ ਐਡਮਿਨ ਟੂਲਿੰਗ ਤੱਕ।
ਤੁਹਾਡਾ ਵੋਟਿੰਗ ਐਪ ਤਦ ਹੀ “ਇਨਸਾਫ਼” ਮਹਿਸੂਸ ਹੋਵੇਗਾ ਜਦੋਂ ਲੋਕ ਸਮਝਣ ਕਿ ਕੌਣ ਕੀ ਕਰ ਸਕਦਾ ਹੈ—ਅਤੇ ਜਦੋਂ ਦੁਰੁਪਯੋਗ ਮੁਸ਼ਕਿਲ ਹੋਵੇ ਬਿਨਾਂ ਵੈਧ ਯੂਜ਼ਰਾਂ ਨੂੰ ਰੋਕਣ ਦੇ। ਛੋਟੇ ਸੈੱਟ ਰੋਲਾਂ ਅਤੇ ਹਰ ਇੱਕ ਨਾਲ ਜੁੜੀਆਂ ਪਰਮਿਸ਼ਨਾਂ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ।
ਸਰਲ ਪਰਮਿਸ਼ਨ ਮਾਡਲ (ਉਦਾਹਰਨ: can_vote, can_post, can_moderate, can_admin) ਲੰਬੇ ਸਮੇਂ ਲਈ ਰੱਖ-ਰਖਾਅ ਵਿੱਚ ਆਸਾਨ ਹੈ।
ਅਧਿਕ ਤਰ feature request ਪੋਰਟਲਾਂ ਲਈ ਈਮੇਲ ਮੈਜਿਕ ਲਿੰਕ ਘੱਟ ਰੁਕਾਵਟ ਵਾਲਾ ਵਿਕਲਪ ਹੈ ਅਤੇ ਪਾਸਵਰਡ ਰੀਸੈੱਟ ਬਚਾਉਂਦਾ ਹੈ। ਪਾਸਵਰਡ ਲਾਗਇਨ ਜਾਣ-ਪਛਾਣਯੋਗ ਹੈ ਪਰ ਸਹਾਇਤਾ ਭਾਰ ਵਧਾਉਂਦਾ ਹੈ। SSO (SAML/OIDC) ਆਮ ਤੌਰ 'ਤੇ ਵਿਕਲਪਕ ਹੈ ਅਤੇ B2B ਯੋਜਨਾਂ ਲਈ ਚੰਗਾ ਰਿਹਾ ਹੈ।
ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਖਾਤਿਆਂ ਵਾਲੀ ਐਪ ਹੈ, ਤਾਂ ਉਹੀ ਆਈਡੈਂਟੀਟੀ ਸਿਸਟਮ ਦੁਬਾਰਾ ਵਰਤੋਂ ਤਾਂ ਜੋ ਯੂਜ਼ਰ ਨੂੰ ਵੱਖਰਾ ਲੌਗਿਨ ਨਾ ਕਰਨਾ ਪਏ।
ਗੈਰ-ਨਾਮੀ ਵੋਟਿੰਗ ਭਾਗੀਦਾਰੀ ਵਧਾ ਸਕਦੀ ਹੈ, ਪਰ ਇਸਨੂੰ ਗੇਮ ਕਰਨਾ ਆਸਾਨ ਹੈ। ਜੇ ਤੁਸੀਂ ਇਸਨੂੰ ਆਗਿਆ ਦਿੰਦੇ ਹੋ, ਤਾਂ ਗਾਰਡਰੇਲ ਲਗਾਓ ਜਿਵੇਂ:
ਪ੍ਰੋਫਾਈਲ ਹਲਕੀ ਰੱਖੋ:
ਸਿਰਫ ਉਹੀ ਇਕੱਠਾ ਕਰੋ ਜੋ ਤੁਸੀਂ ਵਰਤੋਂਗੇ; ਇਹ ਪ੍ਰਾਈਵੇਸੀ ਖਤਰੇ ਘਟਾਉਂਦਾ ਹੈ ਅਤੇ ਆਨਬੋਰਡਿੰਗ ਤੇਜ਼ ਕਰਦਾ ਹੈ।
ਮੂਲ ਤੌਰ 'ਤੇ ਥਰੋਟਲ ਜੋੜੋ ਜਿਵੇਂ “X ਵੋਟ ਪ੍ਰਤੀ ਮਿੰਟ” ਅਤੇ “Y ਨਵੀਆਂ ਬੇਨਤੀਆਂ ਪ੍ਰਤੀ ਦਿਨ।” ਨਵੇਂ ਖਾਤਿਆਂ ਅਤੇ ਗੈਰ-ਨਾਮੀ ਉਪਭੋਗੀਆਂ ਲਈ ਕੜੇ ਨਿਯਮ ਲਗਾਓ, ਅਤੇ ਭਰੋਸੇਯੋਗ ਯੂਜ਼ਰਾਂ (ਪੁਰਾਣੇ ਖਾਤੇ, ਵੈਰੀਫਾਈਡ ਈਮੇਲ, ਜਾਣੇ ਪਛਾਣੇ ਸੰਗਠਨ) ਲਈ ਆਰਾਮ ਦਿਓ।
ਜਦੋਂ ਕੋਈ ਉਪਭੋਗੀ ਸੀਮਾ ਨੂੰ ਛੂਹਦਾ ਹੈ, ਤਾਂ ਇੱਕ ਸਪਸ਼ਟ ਸੁਨੇਹਾ ਅਤੇ ਮੁੜ ਕੋਸ਼ਿਸ਼ ਸਮਾਂ ਦਿੱਖਾਓ ਨਾ ਕਿ ਸਧਾਰਨ ਗਲਤੀ।
ਇੱਕ ਫੀਚਰ ਰਿਕਵੈਸਟ ਪੋਰਟਲ ਆਪਣੀ ਡਾਟਾ ਮਾਡਲ 'ਤੇ ਟਿਕ ਜਾਂ ਡਿੱਗ ਸਕਦਾ ਹੈ। ਜੇ ਰਿਕਾਰਡ ਸੰਗਠਿਤ ਹਨ, ਤਾਂ ਤੁਸੀਂ ਬਿਨਾਂ ਹੱਦ ਦਰਸ਼ਾ ਅਤੇ ਹੱਥੋਂ-ਹੱਥ ਸਾਫ਼-ਸੁਥਰਾ ਕੀਤਾ ਹੋਇਆ ਰਿਪੋਰਟਿੰਗ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੇ ਹੋ।
ਛੋਟਾ ਸੈੱਟ ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਮਕਸਦ ਦਰਸਾਉਂਦਾ ਹੈ:
ਬੈਕਐਂਡ-ਫ੍ਰੈਂਡਲੀ ਫੀਲਡਾਂ ਜੋ ਫਾਲਦੇ ਹਨ: created_by, created_at, updated_at, ਅਤੇ canonical_request_id (ਮਿਲਾਉਣ ਲਈ ਲਾਭਦਾਇਕ)।
ਤੁਹਾਡੀ ਵੋਟ ਟੇਬਲ ਆਮ ਤੌਰ 'ਤੇ user_id → request_id ਨਾਲ ਲਿੰਕ ਹੁੰਦੀ ਹੈ, ਪਰ ਨਿਯਮ ਵੱਖ-ਵੱਖ ਹੋ ਸਕਦੇ ਹਨ:
credits_spent ਪ੍ਰਭਾਵੀ ਰਖੋ।weight ਸਟੋਰ ਕਰੋ ਅਤੇ ਆਡਿਟ ਟਰੇਲ ਰੱਖੋ।ਜੋ ਵੀ ਮਾਡਲ ਚੁਣੋ, ਯੂਨੀਕਨੈੱਸ ਲਾਗੂ ਕਰੋ (ਉਦਾਹਰਣ: ਹਰ ਯੂਜ਼ਰ ਹਰ ਰਿਕਵੈਸਟ ਲਈ ਇੱਕ ਸਰਗਰਮ ਵੋਟ) ਤਾਂ ਜੋ ਟੋਟਲ ਭਰੋਸੇਯੋਗ ਰਹਿਣ।
ਇੱਕ ਪ੍ਰਾਇਕਟਿਕ ਸਥਿਤੀ ਮਾਡਲ ਹੋ ਸਕਦਾ ਹੈ: New → Under Review → Planned → In Progress → Shipped, ਨਾਲ Won’t Do।
status, status_updated_at ਅਤੇ ਜਰੂਰੀ ਹੋਵੇ ਤਾਂ status_reason (ਖਾਸ ਕਰਕੇ Won’t Do ਲਈ) ਸਟੋਰ ਕਰੋ। ਇੱਕ ਹਲਕਾ status_history ਲੌਗ ਪਾਰਦਰਸ਼ਤਾ ਅਤੇ ਰਿਪੋਰਟਿੰਗ ਲਈ ਸੋਚੋ।
ਟਾਪ-ਲੈਵਲ ਫਿਲਟਰਿੰਗ ਲਈ categories ਅਤੇ ਲਚਕੀਲੇ ਲੇਬਲ ਲਈ tags ਵਰਤੋ (ਉਦਾਹਰਣ: “enterprise”, “UI”, “API”)। ਟੈਗਸ many-to-many ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ।
ਟਿੱਪਣੀਆਂ ਅਤੇ ਰਿਐਕਸ਼ਨ ਲਈ, ਪਰਿਭਾਸ਼ਾ ਕਰੋ ਕਿ ਕੀ ਦੀ ਆਗਿਆ ਹੈ: ਟਿੱਪਣੀਆਂ ਰਿਕਵੈਸਟ ਨਾਲ ਜੁੜੀਆਂ, ਇੱਕ ਸੋਧ ਸਮੇਂ-ਖਿੜਕੀ ਦੇ ਅੰਦਰ ਸੋਧਣ ਦੀ ਆਗਿਆ, ਅਤੇ ਰਿਐਕਸ਼ਨ ਇੱਕ ਛੋਟੇ ਸੈੱਟ ਤੱਕ ਸੀਮਤ (ਉਦਾਹਰਣ: 👍/👎) ਜਾਂ ਸਾਰੇ ਬੰਦ ਕਰ ਦਿਓ ਤਾਂ ਕਿ ਸ਼ੋਰ ਘਟੇ।
ਮੋਡਰੇਸ਼ਨ ਫੀਲਡ ਜਿਵੇਂ is_hidden ਅਤੇ hidden_reason ਸ਼ਾਮਲ ਕਰੋ ਤਾਂ ਕਿ ਤੁਸੀਂ ਡੇਟਾ ਮਿਟਾਏ ਬਿਨਾਂ ਗੁਣਵੱਤਾ ਸੰਭਾਲ ਸਕੋ।
ਇਕ ਫੀਚਰ ਰਿਕਵੈਸਟ ਪੋਰਟਲ ਦੀ ਸਫਲਤਾ ਸਪੱਸ਼ਟਤਾ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ: ਲੋਕਾਂ ਨੂੰ ਜਲਦੀ ਸਮਝ ਆਉਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਪ੍ਰੋਡਕਟ ਟੀਮ ਨੂੰ ਕੀ ਚਾਹੀਦਾ ਹੈ, ਕੀ ਪਹਿਲਾਂ ਹੀ ਮੰਗ ਹੋ ਚੁੱਕੀ ਹੈ, ਅਤੇ ਕਿਵੇਂ ਭਾਗ ਲੈਣਾ ਹੈ। ਇਕ ਛੋਟੀ ਸਕਰੀਨ ਸੈੱਟ ਡਿਜ਼ਾਇਨ ਕਰੋ ਜੋ ਯੂਜ਼ਰਾਂ ਨੂੰ “ਮੇਰੇ ਕੋਲ ਵਿਚਾਰ ਹੈ” ਤੋਂ “ਮੈਨੂੰ ਇਸ ਦੀ ਕੀ ਹਾਲਤ ਹੈ” ਤੱਕ ਲੈ ਕੇ ਜਾਵੇ।
ਹੋਮ ਸਕਰੀਨ ਇੱਕ ਫੈਸਲਾ ਪੇਜ਼ ਹੈ। ਇਹ ਜਵਾਬ ਦੇਵੇ:
ਸਧਾਰਨ ਫੀਡ ਮੋਡ ਜਿਵੇਂ Trending ਅਤੇ Newest ਸ਼ਾਮਲ ਕਰੋ। ਜੇ ਤੁਸੀਂ “For you” ਵਿਊ ਦਿੰਦੇ ਹੋ ਤਾਂ ਇਹ ਵਿਵਿਕਲਪ ਰੱਖੋ ਅਤੇ ਦੱਸੋ ਕਿ ਆਈਟਮ ਕਿਵੇਂ ਚੁਣੇ ਗਏ (ਉਦਾਹਰਣ: ਉਹ ਟੈਗ ਜਿਨ੍ਹਾਂ ਨੂੰ ਯੂਜ਼ਰ ਫਾਲੋ ਕਰਦਾ ਹੈ)।
ਹਰ ਕਾਰਡ 'ਤੇ ਸਾਰ-ਸੰਦੇਸ਼ ਦਿੱਖਾਓ: ਸਿਰਲੇਖ, ਛੋਟਾ ਸਾਰ, ਸਥਿਤੀ, ਵੋਟ ਗਿਣਤੀ, ਅਤੇ ਗਤੀਵਿਧੀ ਦੀ ਇੱਕ ਝਲਕ (ਹਾਲੀਆ ਟਿੱਪਣੀ ਜਾਂ ਅਪਡੇਟ)।
ਡੀਟੇਲ ਪੇਜ਼ ਨੂੰ ਇੱਕ ਮਿਨੀ ਕੇਸ ਫਾਈਲ ਵਾਂਗ ਪੜ੍ਹਾਈ ਚਾਹੀਦੀ ਹੈ। ਪ੍ਰਧਾਨ ਰੂਪ ਵਿੱਚ ਇੱਕ ਸਪੱਟ ਪ੍ਰੋਬਲਮ ਸਟੇਟਮੈਂਟ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ (ਉਪਭੋਗੀ ਕੀ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਿਹਾ ਹੈ), ਫਿਰ ਸਮਰਥਕ ਵੇਰਵੇ।
ਸ਼ਾਮਲ ਕਰੋ:
ਮੁੱਖ ਕਾਰਵਾਈਆਂ ਆਸਾਨੀ ਨਾਲ ਮਿਲਣਯੋਗ ਰੱਖੋ: Vote, Follow, ਅਤੇ Copy/share link।
ਘੱਟ ਗੁਣਵੱਤਾ ਵਾਲੀਆਂ ਬੇਨਤੀਆਂ ਅਸਪਸ਼ਟ ਪ੍ਰੰਪਟਾਂ ਤੋਂ ਆਉਂਦੀਆਂ ਹਨ। ਇੱਕ ਛੋਟੀ ਟੈਂਪਲੇਟ ਵਰਤੋ ਜੋ ਯੂਜ਼ਰ ਨੂੰ ਉਪਯੋਗੀ ਇਨਪੁੱਟ ਲਿਖਣ ਲਈ ਪ੍ਰੇਰਿਤ ਕਰੇ:
ਜਿਵੇਂ ਉਹ ਟਾਈਪ ਕਰਦੇ ਹਨ, ਸੁਝਾਈਆਂ ਹੋਈਆਂ ਮਿਲਦੀਆਂ ਬੇਨਤੀਆਂ ਦਿਖਾਓ ਤਾਂ ਜੋ ਯੂਜ਼ਰ ਅਪਵੋਟ ਕਰਨ ਲਈ ਮੌਜੂਦਾ ਆਈਟਮ ਚੁਣ ਸਕੇ।
ਹਰ ਪੇਜ਼ 'ਤੇ ਖੋਜ ਨੂੰ ਪ੍ਰਮੁੱਖ ਬਣਾਓ। ਐਸੇ ਫਿਲਟਰਾਂ ਜੋ ਲੋਕ ਸੋਚਦੇ ਹਨ ਉਸੇ ਅਨੁਸਾਰ ਰੱਖੋ: category, status, tags, ਅਤੇ timeframe (ਉਦਾਹਰਣ: ਪਿਛਲੇ 30 ਦਿਨ)।
ਫਿਲਟਰ UI ਨੂੰ ਕੰਪੈਕਟ ਰੱਖੋ, ਅਤੇ ਯੂਜ਼ਰਾਂ ਨੂੰ URL ਰਾਹੀਂ ਫਿਲਟਰ ਕੀਤੇ ਵਿਊ ਸਾਂਝਾ ਕਰਨ ਦਿਓ।
ਡੁਪਲਿਕੇਟ ਰਿਕਵੈਸਟਾਂ ਅਣਿਵਾਰਯ ਹਨ: ਵੱਖ-ਵੱਖ ਯੂਜ਼ਰ ਇਕੋ ਲੋੜ ਵੱਖ-ਵੱਖ ਸ਼ਬਦਾਂ ਵਿੱਚ ਵੇਖਾ ਸਕਦੇ ਹਨ, ਜਾਂ ਪਹਿਲਾਂ ਹੀ ਮੌਜੂਦ ਫੀਚਰ ਦੀ ਬੇਨਤੀ ਕਰ ਸਕਦੇ ਹਨ। ਡੁਪਲਿਕੇਟਾਂ ਨੂੰ ਚੰਗੀ ਤਰ੍ਹਾਂ ਹੈਂਡਲ ਕਰਨ ਨਾਲ ਬੋਰਡ ਪਠਨਯੋਗ ਰਹਿੰਦਾ ਹੈ ਅਤੇ ਵੋਟਿੰਗ ਮੈਤਲਬਪੂਰਨ ਹੋ ਜਾਂਦੀ ਹੈ।
ਸਪਸ਼ਟ ਪਰਿਭਾਸ਼ਾ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ: ਇੱਕ “ਡੁਪਲਿਕੇਟ” ਉਹ ਬੇਨਤੀ ਹੈ ਜੋ ਇੱਕੋ ਹੀ ਨਤੀਜਾ ਇਕੋ ਯੂਜ਼ਰ ਗਰੁੱਪ ਲਈ ਮੰਗਦੀ ਹੈ, ਭਾਵੇਂ ਇੰਪਲੀਮੈਂਟੇਸ਼ਨ ਵੱਖਰੀ ਹੋਵੇ।
ਜੇ ਦੋ ਪੋਸਟ "ਸੰਬੰਧਿਤ ਪਰ ਵੱਖ-ਵੱਖ" ਹਨ (ਉਦਾਹਰਣ: ਉਤਪਾਦ ਦੇ ਇੱਕੇ ਖੇਤਰ ਪਰ ਵੱਖਰੇ ਯੂਜ਼ਕੇਸ), ਤਾਂ ਉਨ੍ਹਾਂ ਨੂੰ ਵੱਖਰਾ ਰੱਖੋ ਅਤੇ ਰਿਲੇਸ਼ਨ ਟੈਗ ਲਗਾਓ ਬਦਲੇ ਵਿੱਚ ਮਿਲਾਉਣ ਦੇ।
ਮਿਲਾਉਣ 'ਤੇ, ਇੱਕ canonical request ਚੁਣੋ (ਆਮ ਤੌਰ 'ਤੇ ਸਭ ਤੋਂ ਸਪਸ਼ਟ ਸਿਰਲੇਖ, ਸਭ ਤੋਂ ਵਧੀਆ ਵਰਣਨ, ਜਾਂ ਸਭ ਤੋਂ ਪੁਰਾਣਾ ਪੋਸਟ ਜਿਸ 'ਤੇ ਸਭ ਤੋਂ ਵੱਧ ਗਤੀਵਿਧੀ ਹੋਵੇ) ਅਤੇ ਹੋਰਾਂ ਨੂੰ “Merged into #123” ਰਿਕਾਰਡ ਬਣਾਓ।
ਦੋਹਾਂ ਪਾਸਿਆਂ 'ਤੇ ਮਿਲਾਉਣ ਦਾ ਰਿਸ਼ਤਾ ਦਿਖਾਓ:
ਇਸ ਨਾਲ ਗੜਬੜ ਘੱਟ ਹੁੰਦੀ ਹੈ ਅਤੇ "ਮੇਰੀ ਪੋਸਟ ਕਿੱਥੇ ਗਈ?" ਵਾਲੇ ਸਪੋਰਟ ਟਿਕਟ ਘਟਦੇ ਹਨ।
ਵੋਟਸ ਨੂੰ ਆਪ-ਆਪਣੇ canonical ਰਿਕਵੈਸਟ ਵਿੱਚ ਹਿਲਾਓ ਅਤੇ attribution ਪ੍ਰਦਾਨ ਕਰੋ ("ਤੁਹਾਡੀ ਵੋਟ ਨੂੰ … ਵਿੱਚ ਮੋਵ ਕੀਤਾ ਗਿਆ") ਤਾਂ ਕਿ ਯੂਜ਼ਰਾਂ ਨੂੰ ਮਿਟਾਇਆ ਨਹੀਂ ਮਹਿਸੂਸ ਹੋਵੇ।
ਮੋਡਰੇਟਰ ਲਈ ਆਡਿਟ ਟਰੇਲ ਰੱਖੋ (ਕਿਸ ਨੇ ਮਿਲਾਇਆ, ਕਦੋਂ, ਅਤੇ ਕਿਉਂ)।
ਜਿਵੇਂ ਯੂਜ਼ਰ ਸਿਰਲੇਖ ਲਿਖਦਾ ਹੈ, ਬੁਨਿਆਦੀ ਖੋਜ (ਸਿਰਲੇਖ + ਟੈਗ) ਵਰਤੀ ਕੇ ਮਿਲਦੇ-ਜੁਲਦੇ ਰਿਕਵੈਸਟ ਦਿਖਾਓ ਅਤੇ ਉਪਰਲੇ ਮੈਚਾਂ ਨਾਲ ਹੇਠਾਂਤੱਕ ਦਿਖਾਓ। ਇੱਕ ਨਰਮ ਪ੍ਰੰਪਟ "ਕੀ ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਇੱਕੋ ਹੀ ਹੈ?" ਡੁਪਲਿਕੇਟ ਕਾਫੀ ਘਟਾ ਸਕਦਾ ਹੈ।
ਮੋਡਰੇਟਰਾਂ ਨੂੰ ਇੱਕ ਛੋਟੀ ਚੈੱਕਲਿਸਟ ਦਿਓ:
ਸਥਿਰਤਾ ਵਿਸ਼ਵਾਸ ਬਣਾਉਂਦੀ ਹੈ ਅਤੇ ਆਈਡੀਆ ਪ੍ਰਬੰਧਨ ਕਤਾਰ ਨੂੰ ਸੰભਾਲਣਯੋਗ ਰੱਖਦੀ ਹੈ।
ਵੋਟਿੰਗ ਇੱਕ ਫੀਚਰ ਰਿਕਵੈਸਟ ਪੋਰਟਲ ਦੀ ਇੰਜਣ ਹੈ, ਇਸ ਲਈ ਐਸੇ ਨਿਯਮ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ ਜੋ ਆਸਾਨੀ ਨਾਲ ਸਮਝ ਆਉਣ ਅਤੇ ਗੇਮ ਕਰਨਾ ਮੁਸ਼ਕਿਲ ਹੋਵੇ। ਪੇਸ਼ਗੀ ਯੰਤਰਨਾ ਵੀ ਸਹਾਇਕ ਹੈ ਤਾਂ ਜੋ ਸਭ ਨੂੰ ਲਗੇ ਕਿ ਬੋਰਡ ਨਿਆਂਯੁਕਤ ਹੈ।
ਇਹ ਤੈ کریں ਕਿ "ਵੋਟ" ਦਾ ਕੀ ਮਤਲਬ ਹੈ:
ਘੱਟੋ-ਘੱਟ ਲਾਗੂ ਕਰੋ ਹਰ ਯੂਜ਼ਰ ਪ੍ਰਤੀ ਰਿਕਵੈਸਟ ਇੱਕ ਵੋਟ। ਜੇ ਡਾਊਨਵੋਟ ਜਾਂ ਪੌਇੰਟਸ ਹਨ, ਤਾਂ ਉਨ੍ਹਾਂ ਲਈ ਵੀ ਤੁਲਨਾਤਮਕ ਸੀਮਾਵਾਂ ਲਗਾਓ।
ਹਲਕੇ ਘਰੜੇ ਜਿਵੇਂ:
ਜਿਆਦਾਤਰ ਹਾਲਤਾਂ ਵਿੱਚ ਯੂਜ਼ਰਾਂ ਨੂੰ ਵੋਟ ਬਦਲਣ ਜਾਂ ਹਟਾਉਣ ਦੀ ਆਗਿਆ ਦਿਓ—ਜ਼ਰੂਰਤ ਬਦਲਦੀ ਹੈ ਅਤੇ ਰਿਵਰਸੀਬਿਲਟੀ ਨਿਰਾਸ਼ਾ ਘਟਾਉਂਦੀ ਹੈ।
ਜੇ ਤੁਸੀਂ ਪ੍ਰਾਇਓਰਟੀ ਪੌਇੰਟਸ ਵਰਤਦੇ ਹੋ, ਤਾਂ ਰਿਵਰਸੀਬਿਲਟੀ ਬਹੁਤ ਜ਼ਰੂਰੀ ਹੈ ਤਾਂ ਜੋ ਯੂਜ਼ਰ ਆਪਣੇ ਵੰਡੇ ਗਏ ਪੌਇੰਟ ਮੁੜ-ਬਟਾਂ ਸਕਣ।
ਸੋਰਟਿੰਗ ਵਿਹਾਰ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦੀ ਹੈ, ਇਸ ਲਈ ਇਸਨੂੰ ਖੁੱਲ੍ਹਾ ਦੱਸੋ। ਜੇ "Top" ਵੋਟਸ 'ਤੇ ਆਧਾਰਿਤ ਹੈ ਤਾਂ ਇਸ ਨੂੰ ਕਹੋ। ਜੇ "Trending" ਹਾਲੀਆ ਗਤੀਵਿਧੀ ਦੇ ਆਧਾਰ 'ਤੇ ਹੈ ਤਾਂ ਉਹ ਵੀ ਦੱਸੋ।
ਕਈ ਦ੍ਰਿਸ਼ ਦਿਓ: “Top,” “Newest,” ਅਤੇ “Recently Updated” ਨਾਲ ਸਪਸ਼ਟ ਲੇਬਲ।
ਹਦਬੰਦੀ ਜਿਵੇਂ ਹਫ਼ਤੇ ਵਿੱਚ X ਵੋਟ ਜਾਂ ਮਾਸਿਕ ਰਿਫ੍ਰੇਸ਼ ਪੌਇੰਟਸ ਵਰਗੀਆਂ ਨੀਤੀਆਂ ਨਾਲ ਯੂਜ਼ਰਾਂ ਨੂੰ ਸਭ ਕੁਝ ਬਿਨਾਂ ਸੋਚੇ-ਸਮਝੇ ਕਲਿੱਕ ਕਰਨ ਦੀ ਥਾਂ ਮਹੱਤਵਪੂਰਨ ਚੀਜ਼ਾਂ 'ਤੇ ਦਿਣ-ਦੇਣ ਲਈ ਉਤੇਜਿਤ ਕਰੋ।
ਐਡਮਿਨ ਟੂਲਜ਼ ਉਹ ਹਨ ਜੋ ਫੀਚਰ ਰਿਕਵੈਸਟ ਪੋਰਟਲ ਨੂੰ ਯੂਜ਼ ਕਰਨਯੋਗ ਰੱਖਦੇ ਹਨ ਜਦੋਂ ਸਬਮਿਸ਼ਨ ਆਉਣ ਲੱਗਦੇ ਹਨ। ਬਿਨਾਂ ਉਹਨਾਂ ਦੇ, ਬੈਕਲੌਗ ਡੁਪਲਿਕੇਟ, ਅਸਪਸ਼ਟ ਆਈਡੀਆ ਅਤੇ ਗਰਮ ਥ੍ਰੈਡਾਂ ਨਾਲ ਭਰ ਜਾਵੇਗਾ ਜੋ ਤੁਹਾਡੀ ਟੀਮ ਦਾ ਸਮਾਂ ਖਰਚ ਕਰਦੇ ਹਨ।
ਐਡਮਿਨਾਂ ਨੂੰ ਇੱਕ ਥਾਂ ਦਿਓ ਜਿੱਥੇ ਉਹ ਸਮੀਖਿਆ ਕਰ ਸਕਣ:
ਹਰ ਆਇਟਮ ਵਿਚ ਸੰਖੇਪ, ਲੇਖਕ, ਵੋਟ ਗਿਣਤੀ, ਮਿਲਦੇ-ਜੁਲਦੇ ਰਿਕਵੈਸਟ ਅਤੇ ਹਾਲੀਆ ਟਿੱਪਣੀਆਂ ਦਿਖਾਓ ਤਾਂ ਕਿ ਮੋਡਰੇਟਰ ਤੇਜ਼ੀ ਨਾਲ ਫੈਸਲਾ ਕਰ ਸਕੇ।
ਜ਼ਿਆਦਾ ਅਧਿਕਾਰ ਐਡਮਿਨ ਕੰਮ ਦੁਹਰਾਏ ਜਾਂਦੇ ਹਨ। ਬਲਕ ਕਾਰਵਾਈਆਂ ਦਿਓ ਤਾਂ ਜੋ ਮੋਡਰੇਟਰ一หลาย ਆਈਟਮ ਚੁਣ ਕੇ ਇਕੱਠੇ ਬਦਲਾਅ ਲਾ ਸਕਣ:
ਇਹ ਖਾਸ ਕਰਕੇ ਪ੍ਰੋਡਕਟ ਲਾਂਚਾਂ ਦੇ ਬਾਅਦ ਲਾਭਦਾਇਕ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਫੀਡਬੈਕ ਵਧ ਜਾਂਦਾ ਹੈ।
ਜਨਤਕ ਟਿੱਪਣੀਆਂ ਯੂਜ਼ਰਾਂ ਲਈ ਹਨ। ਐਡਮਿਨਾਂ ਨੂੰ ਅੰਦਰੂਨੀ ਸੰਦਰਭ ਲਈ ਇੱਕ ਪ੍ਰਾਈਵੇਟ ਥਾਂ ਚਾਹੀਦੀ ਹੈ: ਸਪੋਰਟ ਟਿਕਟ ਲਿੰਕ, ਆਮਦਨੀ ਪ੍ਰਭਾਵ, ਤਕਨੀਕੀ ਰੋਕਾਵਟ, ਅਤੇ ਫੈਸਲੇ ਦਾ ਕਾਰਨ।
ਅੰਦਰੂਨੀ ਨੋਟਾਂ ਸਿਰਫ ਸਟਾਫ਼ ਲਈ ਦਿੱਖਣਯੋਗ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ ਅਤੇ ਜਨਤਕ ਥ੍ਰੈਡ ਤੋਂ ਅਲੱਗ ਰੱਖੋ ਤਾਂ ਕਿ ਗਲਤੀ ਨਾਲ ਪੋਸਟ ਨਾ ਹੋ ਜਾਣ।
ਮੁੱਖ ਕਾਰਵਾਈਆਂ ਜਿਵੇਂ ਸਥਿਤੀ ਬਦਲਣ, ਮਿਲਾਉਣਾ, ਅਤੇ ਹਟਾਉਣਾ ਟਾਈਮਸਟੈਂਪ ਅਤੇ ਕਰਤਾ ਨਾਲ ਟਰੈਕ ਕਰੋ। ਜਦੋਂ ਕੋਈ ਗ੍ਰਾਹਕ ਪੁੱਛੇ "ਇਹ ਕਿੱਥੇ ਗਈ?\
ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਪੋਰਟਲ ਦਾ ਮੁੱਖ ਮਕਸਦ ਚੁਣੋ:
ਫਿਰ ਸਫਲਤਾ ਮੈਟ੍ਰਿਕ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ (ਗ੍ਰਹਿਣ, ਘੱਟ ਡੁਪਲਿਕੇਟ, ਟਾਈਮ-ਟੂ-ਟ੍ਰਾਇਜੇ). ਇਹ ਲਕੜੀਆਂ ਵੋਟਿੰਗ ਨਿਯਮਾਂ, ਸਥਿਤੀਆਂ ਅਤੇ ਐਡਮਿਨ ਟੂਲਿੰਗ ਨੂੰ ਚਲਾਉਣਗੀਆਂ।
ਇੱਕ ਪ੍ਰੈਕਟਿਕਲ ਘੱਟੋ-ਘੱਟ ਉਪਭੋਗੀ ਵਰਕਫਲੋ:
ਖੋਜ ਨੂੰ ਅਹੰਕਾਰਕ ਥਾਂ ਦਿਓ ਤਾਂ ਜੋ ਉਪਭੋਗੀ ਮੌਜੂਦਾ ਬੇਨਤੀਆਂ ਨੂੰ ਅਪਵੋਟ ਕਰਨ ਜਾਂ ਡੁਪਲਿਕੇਟ ਬਣਾਉਣ ਦੀ ਥਾਂ ਉਨ੍ਹਾਂ ਨੂੰ ਖੋਜ ਸਕਣ।
ਘੱਟੋ-ਘੱਟ, ਤੁਹਾਡੀ ਟੀਮ ਨੂੰ ਇਹ ਟੂਲ ਚਾਹੀਦੇ ਹਨ:
ਜੇ ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਕੰਮ ਐਪ ਤੋਂ ਬਾਹਰ ਹੱਥੋਂ-ਹੱਥ ਹੁੰਦਾ ਹੈ, ਤਾਂ બੋਰਡ ਅਪ-ਟੂ-ਡੇਟ ਨਹੀਂ ਰਹੇਗਾ।
ਇਕ ਸਰਲ, ਰੱਖ-ਰਖਾਅ ਯੋਗ ਮਾਡਲ:
ਪਰਮਿਸ਼ਨਾਂ ਨੂੰ ਝੰਡਿਆਂ (flags) ਵਜੋਂ ਲਾਗੂ ਕਰੋ (ਉਦਾਹਰਣ: , , , ) ਤਾਂ ਜੋ ਰੋਲ ਲਾਜ਼ਮੀ ਤੌਰ 'ਤੇ ਕਠੋਰ ਨਾ ਹੋਣ।
ਆਮ ਵਿਕਲਪ:
ਜੇ ਤੁਸੀਂ ਪਹਿਲਾਂ ਹੀ ਖਾਤਿਆਂ ਵਾਲੀ ਐਪ ਰੱਖਦੇ ਹੋ, ਤਾਂ ਉਹੀ ਆਈਡੈਂਟੀਟੀ ਸਿਸਟਮ ਦੁਬਾਰਾ ਵਰਤੋਂ ਤਾਂ ਜੋ ਯੂਜ਼ਰ ਨੂੰ ਵੱਖਰਾ ਲੌਗਿਨ ਨਾ ਚਾਹੀਦਾ ਹੋਵੇ।
ਤੁਸੀਂ ਇਸਨੂੰ ਆਗਿਆ ਦੇ ਸਕਦੇ ਹੋ, ਪਰ ਗਾਰਡਰੇਲ ਲਗਾਓ ਕਿਉਂਕਿ ਇਹ ਅਸਾਨੀ ਨਾਲ ਗੇਮ ਹੋ ਸਕਦਾ ਹੈ:
ਇਸ ਤਰ੍ਹਾਂ ਭਾਗੀਦਾਰੀ ਵੱਧ ਰਹੇਗੀ ਪਰ ਮੋਡਰੇਸ਼ਨ ਫੁੱਲ-ਟਾਈਮ ਕੰਮ ਨਹੀਂ ਬਣੇਗਾ।
ਰਿਕਵੈਸਟ ਏਨੀਟੀ ਨੂੰ ਛੋਟੇ ਪਰ ਸਥਿਰ ਫੀਲਡਾਂ ਨਾਲ ਰੱਖੋ:
ਬੈਕਐਂਡ ਲਈ ਫੀਲਡ: , , , ਅਤੇ যাতে ਮਿਲਾਣ ਅਤੇ ਰਿਪੋਰ੍ਟਿੰਗ ਆਸਾਨ ਰਹੇ।
ਇੱਕ ਸਾਫ਼ ਮਾਡਲ ਚੁਣੋ ਜੋ ਤੁਸੀਂ ਆਸਾਨੀ ਨਾਲ ਸਮਝਾ ਸਕੋ:
credits_spent ਸਟੋਰ ਕਰੋ)weight ਸਟੋਰ ਕਰੋ ਅਤੇ ਆਡਿਟ ਟ੍ਰੇਲ ਰੱਖੋ)ਜਿਹੜਾ ਵੀ ਮਾਡਲ ਤੁਸੀਂ ਚੁਣੋ, ਇੱਕਟਾਪੀਤਾ ਲਾਜ਼ਮੀ ਕਰੋ (ਉਦਾਹਰਣ: ਇੱਕ ਸਰਗਰਮ ਵੋਟ ਪ੍ਰਤੀ ਯੂਜ਼ਰ ਪ੍ਰਤੀ ਰਿਕਵੈਸਟ) ਤਾਂ ਜੋ ਟੋਟਲ ਭਰੋਸੇਯੋਗ ਰਹਿਣ।
ਡੁਪਲਿਕੇਟ ਨੂੰ "ਉਹੀ ਨਤੀਜਾ ਇੱਕੋ ਯੂਜ਼ਰ ਗਰੁੱਪ ਲਈ" ਵਜੋਂ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ, ਭਾਵੇਂ ਲਫ਼ਜ਼ ਵੱਖਰੇ ਹੋਣ।
ਕਾਰਵਾਈ:
ਮੋਡਰੇਟਰ ਲਈ ਆਡਿਟ ਟ੍ਰੇਲ ਰੱਖੋ ਤਾਂ ਕਿ ਵਿਵਾਦ ਘੱਟ ਹੋਣ।
ਛੋਟਾ ਸੈੱਟ ਘਟਨਾਵਾਂ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਉਪਭੋਗੀ ਉਮੀਦ ਕਰਦੇ ਹਨ:
ਫੋਲੋ/ਸਬਸਕ੍ਰਾਈਬ ਕਰਨਾ ਆਸਾਨ ਬਣਾ ਦੇਓ। ਆਮ ਨਿਯਮ: ਜਦੋਂ ਕੋਈ ਯੂਜ਼ਰ ਬੇਨਤੀ ਭੇਜਦਾ ਹੈ, ਵੋਟ ਕਰਦਾ ਹੈ ਜਾਂ ਟਿੱਪਣੀ ਛੱਡਦਾ ਹੈ ਤਾਂ ਆਟੋ-ਸਬਸਕ੍ਰਾਈਬ ਕਰੋ।
ਇਨ-ਐਪ ਸੂਚਨਾਵਾਂ ਤੇ ਈਮੇਲ ਦੋਹਾਂ ਵਰਤੋ: ਇਨ-ਐਪ ਛੋਟੀਆਂ ਤੇਜ਼ ਫੀਡਬੈਕ ਲਈ; ਈਮੇਲ ਮਹੱਤਵਪੂਰਨ ਅੱਪਡੇਟਾਂ ਲਈ। ਡਾਈਜੈਸਟ (ਰੋਜ਼ਾਨਾ/ਹਫਤਾਵਾਰੀ) ਵਿਕਲਪ ਦੇਣਾ ਵੀ ਚੰਗਾ ਹੈ।
can_votecan_postcan_moderatecan_admincreated_bycreated_atupdated_atcanonical_request_id