I create a repository on GitHub. And I wan't create a issue label Linux, but I input wrong as linux, Now, I wan't change it or delete it, what should I do?
Note: I need to delete a label from all issue not only a single issue issue.
I would suggest to do it via the REST API of GitHub. How to work with lables and issues is documented in the section Lables of the REST API documentation.
You can create the new label manually or also via REST, add the new label to all affected issues and delete the old label. Doing it via the REST API might be the best way if a lot of issues must be changed.
You can also consider to script it via Ruby or JavaScript if you don't want to deal directly via the commandline with the API.
At the first glance it looks like a lot of effort, but it is worth it as you will discover a new and very helpful way to manage your repositories.
This my first time trying to contribute to open source projects. I'm wondering what it means when there is a "pleaseverify" label. Does that mean the team wants someone with experience to verify the bug first before someone else works on it? Or does it mean that I, as a new contributor, have to verify that the bug exist before working on it?
PS. I have googled but cannot find information on the topic.
First, creating a label on GitHub is not linked to some naming convention: you can use any name you want.
Each project has its own convention.
Here, for instance:
I've added the pleaseverify tag just so that we can track or ask for more input from other developers/users that are having the same problem.
There seems to be some consternation about two file types that, in my case, TFS checks in when a new solution or project are created: .vssscc and .vspscc files.
I found a page that describes that these files are for, and yet another that recommends checking them in. I'm perfectly fine with this, but I have heard some grumblings in the internet that these files can cause issues with collaboration between projects, such as merge conflicts and project load errors.
I do recall having some issues in my own organization where the .vspscc file caused some issues, where a developer had caused some edits to it and didn't check it in with the rest of his changes. We were able to repair easily, however.
My question is: what issues should I be aware of, and in the case that issues exist, what precautions can I recommend to my organization to avoid any trouble?
The only issue I've ever come across is a minor annoyance- the .vssscc is included as a change with many checkins even though the .vssscc contents have not changed. I'm guessing the last modified date is being updated.
Apparently Microsoft was looking into fixing this in 2010.
It seems unlikely that these files contain anything of importance to the source code. As far as I can tell it's just cached data about the current code.
I opened an issue at https://github.com/dotnet/project-system/issues/1801, so go there and let them know how this affects you.
I think the answer is no, but maybe I'm missing something: in most repos, you only have one or two admins, and a bunch of "collaborators". But it looks like the collaborators can't assign issues (eg, to themselves), nor can they label issues (even ones they created).
Bug? Design feature? I'm using it wrong? Are there any workarounds?
Looking at Issues 2.0: The Next Generation, this seems to be by design, and from the comments, this isn't the only "problem" users are facing:
It looks like issues can only be assigned to collaborators.
I'd still like to be able to assign an issue (or someone to claim one) to a developer who is not a repo collaborator. After all it is a very common workflow that collaboration happens with forks and pull requests.
One potential workaround (not tested myself) is for a user to fork the original repo, and reproduce the issue in the issue tracker of that new forked repo (that he owns):
the new issue would keep an html link to the original issue of the original repo
the user can assign and label issues.
Obviously that involves a bit of duplication, but for bugs a user wants complete ownership of, that can be worth doing.
Is it possible to completely remove an issue from the GitHub issue tracker?
No, the github API only allows you to open/close/reopen issues. Here's the Issues API docs.
You can edit an existing issue (let's say if it's a duplicate) and you can change the title, description and target milestone to be something completely different. That's as close as you can get to removing the ticket, AFIK.
Update Nov 2018: You now can delete issues if you are a owner of the repository!
See "Github - remove issues entered in error"
https://docs.github.com/en/github/managing-your-work-on-github/deleting-an-issue mentions:
People with admin permissions in a repository can permanently delete an issue from a repository.
For other people (without permission), questionto42's comment shows that you can ask to GitHub support for the issue to be deleted, as illustrated here.
At May 2018, original answer:
Three 8 years later, and closing issues remains the answer (still no deletion possible).
See "The Ghost of Issues Past", where GitHub advise to check and close:
issues opened over a year ago state:open created:<2013-01-01
the ones I'm involved with involves:twp state:open created:<2013-01-01
and those not updated in the last year involves:twp state:open updated:<2013-01-01
For posterity: Deleting issues would be a bad thing, since in general they can be targets of associations on github.
But if you are willing to sacrifice the collaboration info, here is a "whack it with a sledgehammer" approach:
Clone your original repo.
Copy your issues via the Issues API.
Delete the original repo; alternatively, chose a new name for your new repo.
Re-create a new repo based on your clone.
Re-create the issues you want to keep via the Issues API.
I imagine this could potentially lose a lot of other linking information as well such as forks, pull requests, etc.
Public feature request
I wrote to GitHub in 2014-08 and https://github.com/jdennes replied by email:
Thanks for the suggestion. It's only possible to edit/clear the issue content currently. However I've added a +1 to this suggestion on our internal Feature Request List.
confirming it was not possible.
Best workaround so far
set the title to something that will never conflict with any search, e.g. a single dot ..
This may not hide the history of your blunder entirely because of the automatic undeletable "changed the title to" comments.
make the body empty
GitHub staff has the power
If something is a security issue, contact GitHub staff, they usually reply quickly, and are able to remove issues for good as can be seen at: http://archive.is/OfjVt which has issue 1 and 3 but no 2.
You can delete the entire repo if it's really important.
Possible workaround
As of 04/2019 not all issues can be deleted current work around is to edit the issue then delete the edit history, the only downside is that the issue still exist and the old title could be seen.
You could by just asking to github to ban the user that created the issue 😁
Source: https://github.com/isaacs/github/issues/253#issuecomment-290944938
Users are unable to do this, including repository owner.
But issues can be deleted by Github support. One may contact them and request deletion. It may be delayed or refused but it is an available option that can be used.
Still impossible. Another workaround to the ones suggested in the other answers is to label the issue as "deleted" (or any other label you might fancy better), to be able to filter them out if you use the github API to retrieve them. Obviously you should use that specific label only for this purpose, setting the label when you close the issue.
You can create a new repository.
Transfer (yeah it is possible) unwanted issues to the new repository.
Then delete the new repository.