उपयोगकर्ता प्रबंधन

Potato किसी व्यक्ति के बारे में तीन अलग-अलग बातें तय करता है: क्या वह साइन अप कर सकता है, अंदर आने के बाद उसे क्या करने की अनुमति है, और उसे कितना काम दिया जाता है। हर एक के लिए अलग कॉन्फ़िग ब्लॉक है, और इन्हें आपस में मिला देना ही आम तौर पर उस एनोटेटर की वजह होता है जो लॉग इन तो कर लेता है पर उसे कभी कोई आइटम नहीं मिलता।

पहुंच मोड

खुली पहुंच

Potato डिफ़ॉल्ट रूप से स्व-पंजीकरण की अनुमति देता है, इसलिए नया एनोटेटर लॉगिन पेज से अपना खाता खुद बनाता है:

user_config:
  allow_all_users: true

प्रतिबंधित पहुंच

allow_all_users: false सेट करें और उन पतों की सूची दें जिन्हें पंजीकरण की अनुमति है। कोई और खाता नहीं बना सकता:

user_config:
  allow_all_users: false
  users:
    - alice@example.com
    - bob@example.com
    - researcher@university.edu

दोनों कुंजियां user_config के अंदर रहती हैं। शीर्ष स्तर पर लिखे जाने पर इन्हें चुपचाप अनदेखा कर दिया जाता है, और तब यह एक ऐसी पहुंच सूची लगती है जो कुछ नहीं करती।

प्रमाणीकरण

पासवर्ड लॉगिन

यह डिफ़ॉल्ट है। एनोटेटर ईमेल और पासवर्ड से पंजीकरण करते हैं, जिसे Potato प्रति-उपयोगकर्ता सॉल्ट वाले PBKDF2 हैश के रूप में संग्रहीत करता है।

login:
  type: password

URL आर्गुमेंट के साथ डायरेक्ट लॉगिन

url_direct उपयोगकर्ता नाम सीधे एक URL पैरामीटर से लेता है और कोई पासवर्ड नहीं मांगता। क्राउडसोर्सिंग से आने वाले एनोटेटर इसी तरह संभाले जाते हैं:

login:
  type: url_direct
  url_argument: PROLIFIC_PID

इसके बाद एनोटेटर http://your-server:8000/?PROLIFIC_PID=abc123 पर पहुंचते हैं और abc123 के रूप में लॉग इन हो जाते हैं।

url_argument एक सूची भी स्वीकार करता है। उस स्थिति में एनोटेटर के आउटपुट फ़ोल्डर का नाम मानों को आपस में जोड़कर बनता है:

login:
  type: url_direct
  url_argument:
    - PROLIFIC_PID
    - STUDY_ID
    - SESSION_ID

तीन लॉगिन प्रकार हैं password, url_direct और prolific। अंतिम प्रकार URL-डायरेक्ट लॉगिन के ऊपर Prolific API एकीकरण जोड़ता है। प्लेटफ़ॉर्म की ओर के सेटअप के लिए क्राउडसोर्सिंग एकीकरण देखें।

पासवर्ड या लॉगिन फ़ॉर्म बंद करना

हर एनोटेटर किसी यूज़रनेम से साइन इन करता है, क्योंकि Potato हर एनोटेटर के लेबल output_annotation_dir के अंदर उसके नाम वाले फ़ोल्डर में रखता है। कोई भी सेटिंग इस चरण को नहीं हटाती। दो सेटिंग्स इसमें से पासवर्ड हटा देती हैं, और दूसरी सेटिंग फ़ॉर्म भी हटा देती है।

कॉन्फ़िग के शीर्ष स्तर पर require_password: false होने पर लॉगिन फ़ॉर्म केवल यूज़रनेम माँगता है। Potato पहले न देखे गए नाम को उसी समय पंजीकृत कर लेता है, और पहले देखा गया नाम उसी एनोटेटर के काम में वापस साइन इन करता है:

require_password: false

इसलिए जो कोई मौजूदा यूज़रनेम टाइप करता है, वह उस एनोटेटर का सत्र जारी रखता है। पासवर्ड तभी बंद करें जब एनोटेटर एक-दूसरे पर भरोसा करते हों या टास्क का URL निजी हो। इस मोड में भी यूज़र सूची लागू रहती है, और user_config.allow_all_users: false के साथ users में न मौजूद नाम अस्वीकार कर दिया जाता है। फ़ॉर्म भी हटाने के लिए url_direct लॉगिन इस्तेमाल करें और हर एनोटेटर को उसका यूज़रनेम वाला लिंक भेजें। पासवर्ड-रहित लॉगिन उन ऑथेंटिकेशन बैकएंड की सूची देता है जो बिना पासवर्ड के चलते हैं।

भूमिकाएं और अनुमतियां

साझा एडमिन कुंजी

admin_api_key एक ही साझा कुंजी है जो X-API-Key हेडर के रूप में भेजी जाती है, और यह हर अनुमति जांच को बायपास कर देती है। सेट न होने पर Potato एक कुंजी बनाता है और उसे {task_dir}/admin_api_key.txt में लिख देता है।

admin_api_key: "your-shared-key"

भूमिका-आधारित पहुंच नियंत्रण

rbac ब्लॉक होने पर नामित लोग साझा कुंजी रखे बिना, सामान्य रूप से लॉग इन करके एडमिन डैशबोर्ड तक पहुंचते हैं:

rbac:
  enabled: true
 
  # Custom roles, merged over the built-in ones
  roles:
    lead: [view_admin_dashboard, export_data, annotate]
 
  # Assign roles to specific users
  user_role_assignments:
    carol@example.com: admin
    dave@example.com: lead
 
  # Map an SSO claim to a role
  sso_role_mapping:
    "org:my-github-org": adjudicator

अनुमतियां हैं view_admin_dashboard, manage_assignment, adjudicate, export_data और annotate। बिल्ट-इन admin भूमिका के पास पांचों हैं, adjudicator के पास adjudicate, export_data और annotate हैं, और annotator के पास annotate है।

किसी उपयोगकर्ता की अनुमतियां उसकी हर भूमिका की अनुमतियों का संघ होती हैं। अगर rbac ब्लॉक है ही नहीं, तो केवल साझा कुंजी और adjudication.adjudicator_users सूची ही उन्नत पहुंच देती हैं। RBAC से पहले लिखे गए प्रोजेक्ट इसी तरह काम करते रहते हैं।

कार्यभार

प्रति एनोटेटर सीमा

max_annotations_per_user सभी के लिए एक संख्या सेट करता है:

max_annotations_per_user: 100

per_annotator_quota अलग-अलग लोगों के लिए अलग-अलग संख्याएं सेट करता है। यह default, by_user और by_user_role स्वीकार करता है, और किसी भी अन्य उप-कुंजी को अनदेखा करने के बजाय लोड के समय अस्वीकार कर देता है:

per_annotator_quota:
  default: 50
  by_user:
    alice@example.com: 200
  by_user_role:
    expert: 150
    novice: 40

सीमा तय करने के लिए पहले by_user, फिर by_user_role, फिर default देखा जाता है। भूमिका लेबल user_roles से आते हैं:

user_roles:
  alice@example.com: expert
  bob@example.com: novice

यहां का लेबल केवल कार्यभार लेबल है। यह अनुमतियां तभी देता है जब यह rbac.roles में किसी भूमिका का नाम भी हो, इसलिए expert और novice केवल कोटा लेबल ही रहते हैं।

प्रति आइटम एनोटेटर

num_annotators_per_item बताता है कि हर आइटम कितने लोग देखते हैं। यही तय करता है कि अंत में आप सहमति रिपोर्ट कर सकते हैं या नहीं:

num_annotators_per_item: 3
min_annotators_per_instance: 2

max_annotations_per_item इसी सीमा का एक पदावनत (deprecated) उपनाम है। दोनों को अलग-अलग मानों पर सेट करने पर लोड के समय अस्वीकार कर दिया जाता है, चुपचाप हल नहीं किया जाता।

असाइनमेंट रणनीति

assignment_strategy: random
random_seed: 1234

रणनीतियां हैं random, fixed_order, least_annotated, max_diversity, diversity_clustering, category_based, batch, priority, model_review, llm_confidence, psychometric और active_learning। random_seed का डिफ़ॉल्ट 1234 है, इसलिए जब किसी रन को दोहराने योग्य होना हो तो इसे निश्चित करें। हर रणनीति क्या करती है, इसके लिए कार्य आवंटन देखें।

एनोटेटर को योग्य बनाना

प्रशिक्षण चरण असली कार्य से पहले एनोटेटर के सामने ज्ञात उत्तरों वाले अभ्यास आइटम रखता है, और passing_criteria तय करता है कि कौन आगे बढ़ेगा:

training:
  enabled: true
  data_file: data/training.json
  passing_criteria:
    min_correct: 8
    max_mistakes: 2
    max_mistakes_per_question: 1
  allow_retry: true
  failure_action: block

आइटम फ़ॉर्मैट और फ़ीडबैक विकल्पों के लिए प्रशिक्षण चरण देखें।

कार्य के दौरान ध्यान की जांच

प्रशिक्षण शुरुआत में लोगों को छांटता है। ध्यान जांच असली काम शुरू होने के बाद भी मापना जारी रखती है:

attention_checks:
  enabled: true
  items_file: data/attention_checks.json
  frequency: 10
  min_response_time: 3.0
  failure_handling:
    warn_threshold: 2
    warn_message: "Please read items carefully before answering."
    block_threshold: 5
    block_message: "You have been blocked due to too many incorrect responses."

गोल्ड स्टैंडर्ड और सहमति रिपोर्टिंग के लिए गुणवत्ता नियंत्रण देखें।

सत्र

secret_key: "a-long-random-string"
session_timeout_minutes: 60
persist_sessions: true
session_lifetime_days: 7

secret_key सत्र कुकी पर हस्ताक्षर करती है, और यह इसके बजाय POTATO_SECRET_KEY एनवायरनमेंट वेरिएबल से भी आ सकती है। इसके बिना Potato हर स्टार्टअप पर एक नई कुंजी बनाता है, जिससे हर रीस्टार्ट पर सभी लॉग आउट हो जाते हैं।

session_timeout_minutes उस सत्र को मिटा देता है जो इतनी देर से निष्क्रिय है, और हर अनुरोध पर घड़ी फिर से शुरू होती है। Potato 2.11 पहली रिलीज़ है जो इसे लागू करती है, और इसका डिफ़ॉल्ट 480 मिनट है। इस उदाहरण की तरह 60 पर, जो एनोटेटर एक घंटे के लिए उठकर चला जाता है, उसे लौटने पर फिर से लॉग इन करना पड़ता है।

उदाहरण: शोध टीम सेटअप

annotation_task_name: "Sentiment Annotation"
task_dir: .
 
user_config:
  allow_all_users: false
  users:
    - researcher1@university.edu
    - researcher2@university.edu
    - student1@university.edu
    - student2@university.edu
 
rbac:
  enabled: true
  user_role_assignments:
    researcher1@university.edu: admin
 
user_roles:
  researcher1@university.edu: expert
  student1@university.edu: novice
 
per_annotator_quota:
  default: 200
  by_user_role:
    expert: 300
    novice: 120
 
num_annotators_per_item: 2
assignment_strategy: least_annotated
 
data_files:
  - data/main.json
 
item_properties:
  id_key: id
  text_key: text
 
annotation_schemes:
  - annotation_type: radio
    name: sentiment
    description: "What is the sentiment of this text?"
    labels:
      - Positive
      - Negative
      - Neutral
    sequential_key_binding: true
 
output_annotation_dir: annotation_output/

उदाहरण: क्राउडसोर्सिंग सेटअप

annotation_task_name: "Sentiment Annotation Study"
task_dir: .
 
login:
  type: url_direct
  url_argument: PROLIFIC_PID
 
completion_code: "POTATO2024"
 
user_config:
  allow_all_users: true
 
max_annotations_per_user: 50
num_annotators_per_item: 3
assignment_strategy: random
 
hide_navbar: true
jumping_to_id_disabled: true
 
attention_checks:
  enabled: true
  items_file: data/attention_checks.json
  frequency: 10
  failure_handling:
    warn_threshold: 2
    block_threshold: 5
 
data_files:
  - data/main.json
 
item_properties:
  id_key: id
  text_key: text
 
output_annotation_dir: annotation_output/

आगे पढ़ें

• पासवर्ड-रहित लॉगिन - URL-आधारित प्रमाणीकरण
• कार्य आवंटन - एनोटेशन वितरण नियंत्रित करें
• क्राउडसोर्सिंग एकीकरण - Prolific, SONA और अन्य पैनल
• प्रशिक्षण चरण - कार्य से पहले एनोटेटर को योग्य बनाना

कार्यान्वयन विवरण के लिए स्रोत दस्तावेज़ और भूमिकाएं और अनुमतियां संदर्भ देखें।