Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Policy does not clearly state limits on responses from people-in-charge. #20

Open
piroton opened this issue Oct 2, 2019 · 2 comments
Open
Assignees

Comments

@piroton
Copy link
Member

piroton commented Oct 2, 2019

At the current, policy does not dictate how long a reasonable timeframe should be on replies.

There is also a distinct lack of prior rulings and how finer processes should be done. However, these are meant to be guiding policies at the outset, and not straight up rules - though that can certainly be arranged.

@piroton piroton self-assigned this Oct 2, 2019
@lyqht
Copy link
Contributor

lyqht commented Nov 2, 2019

My suggestion:

  • A reasonable time frame for replies from both the assignees & the issue raiser should be 1 working day from the time that the issue is raised.
    • If either side do not respond within the time frame, it is the responsibility of the other party to bump it. With this, if there is still no response, the issue will be closed, and the unresponsive party will be responsible for their actions.
    • If there is no bump, the issue is assumed to have been resolved.
  • With this requirement, clubs are also mandated to raise requests for locked rooms to be opened minimally 2 working days before the requested date.

@Kazykiddo
Copy link

To add on, depending on type of request, we can have the window for the room to be open varied.

For example, if the request of simply to open for retrieval of items, a time frame of 1 hour should be more than sufficient, unless there are specific reasons for the room to be open for a longer frame of time.

An example of a larger frame of time for the room to be open, would be for users to do stock take, or hand/takeover, which might require more than an hour.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants