I want to archive an old pool in Toloka, which I no longer need. I have created new ones to label new batches and the old ones are just interrupting my work I can't find a button.
In Toloka, there is a restriction on archiving pools with unreviewed or rejected tasks. This is because you can't change the task status in archived pools, like review a submitted response or accept a previously rejected task. You can't archive a pool that contains tasks rejected less than 9 days ago.
https://yandex.com/support/toloka-requester/concepts/pool-archive.html
Related
Does MarkLogic DLS offer a similar file versioning experience to subversion?
Under Subversion, once the file(document) has been locked, others could not update it anymore, unless the file has been committed (check-in) or released the lock.
However in MarkLogic Library Services (DLS), once the document has been checked out, others could still call dls:document-checkout-update-checkin to update and release the lock. Does it mean it is the developer who should use those dls functions to implement the file lock and unlock mechanism?
I tried to use the timeout parameter in dls:doucment-checkout. However, it seems the document will remain in the checkout status forever. But I do see that parameter when I call 'dls:coument-checkout-status'.
Does it mean that it is the developer who should check the server timestamp together with the initial checkout timestamp and timeout duration to determine whether the file is still in lock status?
If so, I will need to write some XQuery programs and set up a scheduled task in ML to clean up the file checkout daily. Is my above understanding correct?
Per https://docs.marklogic.com/guide/app-dev/dls#id_56448, I believe the timeout is not enforced automatically - i.e. there's no background process in MarkLogic that is periodically inspecting documents to see if they should be automatically checked back in or un-checked out. The timeout appears to be meant to be used by a developer to apply their own logic with it - e.g. allowing a UI to state that "Jane checked this document out and only intended to keep it for 10 minutes, but that was 2 hours ago - would you like to break her checkout?"
How come the reviewer know the task is of high priority? Is there any provision for the client to inform the reviewer that the form need to review soon.
Also how the client came to know that the application submitted is rejected/returned?
The client as a user isn't actually the one who should be setting the task as high priority. It should be either a admin user/ another reviewer user who is supposed to assign whether a task is of high priority or not. It can be done by setting Due dates in task details section to signify the task is of high priority and should be completed quickly.
To answer the second question, the client can know the application status by checking the application history tab and understand the progress of their application.
We've been doing a bunch of bulk fixing of issues in our codebase (deprecated code usage, mostly) and every time the analysis kicks off next, everyone gets 10-100-1000 individual emails detailing the status changes that occurred.
Is there any way to consolidate all this information into a single email so users don't end up being unable to tell what's going on due to sheer bulk of repetitive information?
I really don't want to have to turn off the notification emails and implement my own email mechanism if I've just missed a setting or plugin somewhere.
You can change the user notification subscriptions. Here are the different notifications a SonarQube can set in 6.7:
Background tasks in failure on my administered projects
Changes in issues assigned to me
New quality gate status
Issues resolved as false positive or won't fix
New issues
My new issues
Either keep only “My new issues” or unassign issues that will not be fixed by the author.
There's an issue that is linked to the problem raised. Feel free to vote for it.
I created a bucket in a project. I subsequently deleted that project, so its bucket should be deleted along with it.
Now I'm attempting to make a bucket with the same name in another project, but I get the error:
"This bucket name is already in use. Bucket names must be globally unique. Try another name."
It's been over 12 hours. Documentation suggests that bucket IDs are supposed to get released if they are no longer in use. Will that bucket ID ever become available again?
From the support documentation:
Shutting down a project stops all billing and traffic serving, shuts
down any Google Cloud Platform App Engine applications, and terminates
all Compute Engine instances. All project data associated with Google
Cloud and Google APIs services becomes inaccessible.
After a 7-day waiting period, the project and associated data are
permanently deleted from the console.
Note that after the 7-day waiting period ends, the time it takes to
completely delete a project may vary. For example, if a project has
billing set up, it might not be completely deleted until the current
billing cycle ends, you receive the next bill, and your account is
successfully charged. Additionally, the number and types of services
in use may also affect when the system permanently deletes a project.
I released a new iPhone app 5 days ago. Already it has received high ratings, and many downloads, so I think it can be quite successful. (It's currently ranked in the top 10 paid music apps.)
What do you think is the best release strategy:
Release many micro-updates, often. (Just 1 or 2 new features per update, as they are completed.)
or
Release major updates less frequently. (Perhaps one new version every 1 or 2 months.)
The app is currently priced at $0.99 USD. Originally I planned to raise the price after the first major update. But if the app continues to sell well, I may leave the price alone.
Just curious to know how others have handled their app release cycles. Thanks!
Apple suggests (here):
High frequency updates - crashes or data loss
Updates to your application
that address crashing and data loss
should be submitted as frequently as
necessary. Fixing as many related bugs
as possible in each update is highly
recommended.
Medium frequency updates - minor
enhancements and usability
improvements Consider a release
schedule between two to four weeks
that groups together updates which do
not affect the core functionality of
your application, such as user
interface improvements, spelling
corrections, and minor functionality
enhancements.
Low frequency updates - new features
Applications with new features should
be submitted on a periodic, monthly
basis. A high frequency of new feature
updates suggests poor development
planning and can be confusing to your
customers.customers.
They say that submitting updates really often may impact the time it takes for your updates to get approved, (because each update has to be checked manually by the app store reviewers).
One reason for not updating too frequently is that frequent updates can be annoying to users. Each time, they have to key in their password and wait for it to download the update.