185
|
1 |
{% extends 'base.html' %}
|
|
2 |
{% block title %}
|
|
3 |
PyTasks - About - Task life cycle
|
|
4 |
{% endblock %}
|
|
5 |
{% block content %}
|
|
6 |
The task is created by a user and will start life in unpublished state. The creator has all rights over the task. The task in this
|
|
7 |
stage will be visible only to the creator. He can anyways request other users to view and review the task. Then the requested user
|
|
8 |
can view the task untill he does not reply to the request. If the user accepts the request, he can view, edit and comment on the task.
|
|
9 |
The user can also add/remove subtasks or dependencies. If he rejects the request he is just like other users and cannot view the task.
|
|
10 |
When the creator decides the task is ready to be published, he publishes the task. Through out this phase,
|
|
11 |
the creator of the task can delete the task at any point in time.
|
|
12 |
<br /><br />
|
|
13 |
|
|
14 |
If the task survives and is published, the task is available to be viewed by all the users. The task cannot be edited after this
|
|
15 |
point but subtasks/dependencies can be added/removed. If the task has subtasks, the task is locked forever. It implies that the task
|
|
16 |
cannot be claimed by anyone and exists only to show all of its subtasks in one place.<br /><br />
|
|
17 |
If a task has dependencies, the task is locked untill all of its dependencies are completed. If all its dependencies are completed,
|
|
18 |
the task is open for claims and can be claimed by users.
|
|
19 |
If a task has neither subtasks nor dependencies, it is open as well and users claim the task. Any of the mentors can select user(s)
|
|
20 |
from the claimed users to work on the task . Dependencies can be added/removed only untill a user is selected to work on the task. This is due
|
|
21 |
to the fact that user had a chance to claim when the task had no dependencies or all its dependencies were satisfied.
|
|
22 |
Also selecting a user to work on the task implies the task has all its dependencies satisfied.<br /><br />
|
|
23 |
|
|
24 |
During the working stage of task, a mentor can request assign of pynts to users working on task or the mentors. The assign pynts link
|
|
25 |
will be available to mentor on the task page. If there are no users working, the mentor can request assign of credits to himself
|
|
26 |
or one of the other mentors, who ever has done work on the task. Even if there are no users working on task, if there is a
|
|
27 |
request for assign of credits to the task implies that someone has worked on the task and hence dependencies cannot be
|
|
28 |
added after that.<br /><br />
|
|
29 |
|
|
30 |
After a considerable amount of work has been done and all the users and mentors have been assigned pynts properly, any mentor in the
|
|
31 |
task can mark the task as complete. The link is available on assign pynts page just in case
|
|
32 |
the mentor wants to assign more pynts before marking the task as complete.<br/>
|
|
33 |
If a mentor feels that the task is invalid or decides to delete the task, he will not be allowed to do it. Instead he can close the task
|
|
34 |
by providing a closing message. The link to close task will be available to mentors on the task page itself.<br /><br/>
|
|
35 |
|
|
36 |
Now all this can be done by any of the mentors and hence think twice before you request a user to mentor the task.
|
|
37 |
{% endblock %}
|