giseldo/neodataset huggingface dataset:
Change the default branch from `master` to `main`

In order to support the discussion and our initiative of changing the default branch name, we should follow this [GitLab Issue](https://gitlab.com/gitlab-org/gitlab/-/issues/221164) 

Let's rename `master` to `main`

- [x] Make sure any branch name depending scripts are updated
- [x] Make sure there are no blockers to make this change
- [x] Change the contribution guidelines to reflect the non-standard default branch name
- [x] Set `main` as default branch
- [x] change target branch of all open merge requests to `main`
- [x] unprotect `master`, delete it, and protect `master` branch again, allowing no one to create it
- [x] propagate the changes to the [security repo](https://gitlab.com/gitlab-org/security/gitlab-vscode-extension)

A similar project that just went through this change: https://gitlab.com/gitlab-org/gitlab-svgs/-/issues/127#note_378289361

Story points: 1.0
"Validate GitLab CI config" requires project for local file import

<!---
Please read this!

Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label:

- https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/issues?label_name%5B%5D=bug

and verify the issue you're about to submit isn't a duplicate.
--->

### Summary

"Validate GitLab CI config" requires project for local file import. According to GitLab's online validator and documen tation this is incorrect

### Steps to reproduce

Create two file config in single repo. Open .gitlab-ci.yml and run "GitLab: Validate GitLab CI config"

//.gitlab-ci.yml
```
stages:
    - echo

include:
    - local: child.gitlab-ci.yml
```

// child.gitlab-ci.yml
```
stages:
    - echo

echo:
    stage: echo
    image: ruby:2.6
    script:
        - echo "echo"
```


### What is the current *bug* behavior?

Validation fails with error "Local file `child.gitlab-ci.yml` does not have project!"

### What is the expected *correct* behavior?

Should say "Your CI configuration is valid."

### Relevant logs and/or screenshots

(Logs can be found by running `Developer: Show Logs ...` command (using `cmd+shift+p`) and selecting `Extension Host`)

### Possible fixes

(If you can, link to the line of code that might be responsible for the problem)

Story points: 1.0
Poll for branch information only in active window

### Problem to solve

If the user opens multiple extension windows, all of those windows are going to be polling pipeline information (each 30s) and open MR and closing issue (each 60s) for the current branch. This could result in increased load on the API and issues like #211

### Proposal

The polling should only happen when the extension window is [`focused`](https://code.visualstudio.com/api/references/vscode-api#WindowState). Same way as the native `git` extension polls for remote branch changes.

We should also start to poll immediately after the window comes into focus ([`window.onDidChangeWindowState`](https://code.visualstudio.com/api/references/vscode-api#window.onDidChangeWindowState)).

### Further details

- https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/blob/ec80a6f81d5d9b5b402dcf8ad50f5ad45c21800b/src/status_bar.js#L121
- https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/blob/ec80a6f81d5d9b5b402dcf8ad50f5ad45c21800b/src/status_bar.js#L184

### Links / references

I assume the official `git` extension implementation to be somewhere here https://github.com/microsoft/vscode/blob/master/extensions/git/src/statusbar.ts

The official VS Code extension API offers a [`WindowState`](https://code.visualstudio.com/api/references/vscode-api#WindowState) which allows us to find out whether the window is focused or not.

Story points: 2.0
Create a open-vsx account

In order to be allowed to publish to https://open-vsx.org/ we need a token and a publisher account.
I would follow the same we use on the vscode marketplace.

- [x] Create a GitHub account for open-vsx with the `vscode@gitlab.com` email address
- [x] Create the `gitlab` publisher on open-vsx
- [x] Make sure login credentials are in the shared 1Password vault
- [x] Retrieve a token that can be used for publishing
- [x] Add the token to CI/CD configuration of [this project](https://gitlab.com/gitlab-org/gitlab-vscode-extension) as `OPENVSX_ACCESS_TOKEN` (same settings as `AZURE_ACCESS_TOKEN`)
- [x] Add the token to CI/CD configuration of the [security project](https://gitlab.com/gitlab-org/security/gitlab-vscode-extension) as `OPENVSX_ACCESS_TOKEN`
- [x] Claim the `GitLab` publisher namespace https://github.com/eclipse/open-vsx.org/issues/103

/cc @viktomas @phikai

Story points: 1.0
Publish GitLab Workflow extension to Open VSX Registry

## Problem to Solve

Currently there are users who use VS Code alternatives like [VS Codium](https://github.com/VSCodium/vscodium), [Theia](https://theia-ide.org/) and others which are generally OSS alternatives to VS Code. In most cases, these editors are able to run VS Code extensions, but the VS Code marketplace is unavailable for normal distribution.

## Additional Details

[Open VSX](https://open-vsx.org) is an open-source registry for VS Code extensions. It can be used by any development environment that supports such extensions.

Additional information on how to publish an extension to Open VSX can be obtained [here](https://github.com/eclipse/openvsx/wiki/Publishing-Extensions).

## Proposal

In order to make the GitLab Workflow extension more accessible to more users we should also automate publishing of the extension to the Open VSX registry.

<details><summary>Original Description</summary>
I'm a [VS Codium](https://github.com/VSCodium/vscodium) user, a FLOSS version of VS Code. It's the same code but without Microsoft's telemetry, branding and licensing.

I would like to request, if possible, to add the **GitLab** extension to the [open-vsx.org](https://open-vsx.org) market as it is unclear if it's legal to use the official Microsoft extension marketplace on VS Code forks, see [here](https://github.com/microsoft/vscode/issues/31168).

Additional information on how to publish an extension to Open VSX can be obtained [here](https://github.com/eclipse/openvsx/wiki/Publishing-Extensions).
</details>

Story points: 2.0
Update contribution guidelines

### Problem to solve

The contribution guidelines are not in line with GitLab standards.

### Proposal

- [x] Add DCO + License info at the top (see an example at https://gitlab.com/gitlab-org/gitlab-runner/-/blob/master/CONTRIBUTING.md)
- [x] Remove the separate [code of conduct file](https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/blob/master/CODE_OF_CONDUCT.md). Just have a link to the [Code of conduct page](https://about.gitlab.com/community/contribute/code-of-conduct/) as a SSOT in the [CONTRIBUTING.md](https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/blob/master/CONTRIBUTING.md) file
- [x] Remove "Reporting Issues" and "Proposing Features" sections and only point to the templates
- [x] Revisit the practical setup sections

### Further details

### Links / references

Story points: 2.0
Automated testing strategy

### Problem to solve

There are no automated tests for the extension (with exception of [unit test for `parseGitRemote` function](https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/blob/master/test/unit_tests/git_service.test.ts)). We need to increase our automated test coverage to be able to make changes to the extension without introducing regressions.

### Proposal

Create a testing strategy for the extension.

*Personal opinion: At the beginning, we should focus on the highest level tests (integration/e2e). There is a lot of suggested work that is taking out major parts of the codebase (!53 !54 ). Unit tests written for these soon-to-be-replaced parts might not be the best use of our efforts*

### Acceptance criteria

- Testing pyramid for our VS Code Extension is described (i.e. what kind of tests we'll implement)
- Implement at least one example test for each level of testing (e.g. If we'll have unit tests, functional tests, and E2E tests, then at least one unit test, functional test, and E2E test).
- Example tests are reliably running in our CI

### Links / references

- My personal extension having [integration and unit tests](https://gitlab.com/viktomas/gitlab-example-extension/-/blob/integration-tests/.gitlab-ci.yml#L13-29)
- Testing guide in the official documentation https://code.visualstudio.com/api/working-with-extensions/testing-extension

Story points: 3.0
Automated CHANGELOG entries creation

### Problem to solve

New entries are added to CHANGELOG ad-hoc, which results in more manual work and inconsistencies in the changelog entries.

### Proposal

Implement a mechanism similar to the one used `gitlab-org/gitlab` (https://docs.gitlab.com/ee/development/changelog.html). Each MR that introduces significant user-facing change would create a changelog entry. These entries would get compiled into a version changelog during the release of the new version.

Improving even further we could utilize the [releases](https://docs.gitlab.com/ee/user/project/releases/) feature which we've started using for GitLab. Example: https://gitlab.com/gitlab-org/gitlab/-/releases#v13.1.0-ee

### Links / references

- Example changelog entries: https://gitlab.com/gitlab-org/gitlab/tree/master/changelogs/unreleased/
- Ruby script for generating changelog entries: https://gitlab.com/gitlab-org/gitlab/-/blob/master/bin/changelog

Story points: 2.0
Opening the same MR or Issue in webview multiple times causes duplicated tabs

I just noticed that when selecting an Issue or Merge Request I have already opened once, it opens another tab instead of showing the already existing tab.
This can cause the tab-bar to get full very quickly if you don't track what you already opened and is not how VSCode itself handles these things, so it's a bit annoying.

I know that the Issue and MR-Features are still experimental but wanted to point this strange behaviour out anyway.

* VSCode Version: 1.44.2 (ff915844119ce9485abfe8aa9076ec76b5300ddd)
* Extension version: 2.2.0
* OS: Arch Linux on 64bit Desktop-PC

## Screenshots

![Kapture_2020-06-29_at_10.06.24](/uploads/119fd679f949793d7ca7b4dfcc2d15d4/Kapture_2020-06-29_at_10.06.24.gif)

## Possible solution

If we use the VS Code native [Uri](https://code.visualstudio.com/api/references/vscode-api#Uri) to identify each issue and MR webview, we could avoid duplication without us writing any custom code.

Story points: 2.0
Click on merge request in status bar should open the webview

Since one of the last versions, GitLab Workflow has this merge request detail view which opens when I click on a merge request from the list in the sidebar.

For user interaction consistency, I think this should also be the case when I click on the merge request link in the status bar.

*Note: the webview needs to be enabled as an [experimental feature](https://gitlab.com/gitlab-org/gitlab-vscode-extension#experimental-features).*

![Kapture_2020-06-25_at_11.10.06](/uploads/fb8ce39650c94975e314149b21f93f84/Kapture_2020-06-25_at_11.10.06.gif)


![image](/uploads/26516ec1c3bbac5070f5fedfbf156961/image.png)

Story points: 1.0
3.0.0 Release

## Summary

Version `3.0.0` is the next major release of the extension. See details in the [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/blob/master/CHANGELOG.md#v300-tbd).

## Testing strategy

- Testing new features of this release.
  - [x] Multi-root workspaces
    - VS Code documentation: https://code.visualstudio.com/docs/editor/multi-root-workspaces
    - Tested: tree view with issues, snippets, custom queries
  - [x] New icon (lines instead of fill)
  - [x] Custom queries
    - :question: The custom queries completely replace the default queries
    - works well even with multi-root workspaces
- Testing fixes in this release
  - [x] Creating snippets
  - [x] Improve remote URL parsing to support non-standard Gitlab usernames.
      - The implementatoin seems good to me. I don't have access to gitlab instance with different git user.
      - During testing weird names I discovered and fixed https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/issues/197
  - [x] Click on merge request "for current branch" doesn't do anything
- [x] Sanity testing
  - this release introduces 16k changed lines of code, part of the testing should be generic happy-path testing of the extension's [Feature set](https://gitlab.com/gitlab-org/gitlab-vscode-extension#features).

<details>
<summary>Original descriptiom</summary>

Hi @fatihacet 

we should be ready for 3.0.0 release. Before go ahead with the release_checklist.md, would you mind to test the attached packaged extension to be sure we are not breaking anything?

Thank you

[gitlab-workflow-3.0.0.vsix](/uploads/2b7ef51cb938ff5bd0b3b7afcabb6855/gitlab-workflow-3.0.0.vsix)

</details>

Story points: 4.0
"Password found in breach" message for good password

# Bug Report
<!--
Thank you for taking the time to report a bug! Before continuing, please make
sure the bug hasn't been reported before by searching through the other issues.
This will save both yourself and us some time. If you're sure there isn't
another issue, continue through the template below. All the text between
the opening and closing arrows (HTML comments) will not be shown in the end
result.
-->



## Platform
<!-- When possible, please provide what version you're running. -->

* Operating System: Linux Mint 19.3 Cinnamon
* Browser: Firefox 76.0



## What is happening and/or broken?
<!-- Provide as many details as you can and if possible a little step-by-step
guide so that we can reproduce the issue. Screenshots or a video that shows the
problem also help immensely. -->
I tried to change my password using an automatically-generated password from Bitwarden. I was shocked to receive the message that this password had been pwned. When I checked on https://haveibeenpwned.com/Passwords, though, it said this password has not been found in any breaches.

Here it is:
MZz7TbtdiVWW97


## What is expected to happen?
<!-- Explain what the expected result is if it's not clear from how it is
broken. You can omit this if the expected result is just "It should work" or
similar. -->
Either give a message saying symbols are required or something, or allow me to use it if it's a valid password.

Story points: 1.0
Un-pin and upgrade Salt in Vagrantfile

As described in [the message for the commit where I pinned the version](https://gitlab.com/tildes/tildes/-/commit/4dc99d9fda4b3282d7dc00a65e5196d8fc95b66e), a new version of Salt has been released but is currently buggy and breaks creating a Tildes dev environment since it can't handle `unless` checks.

I've pinned Salt to the previous stable version for now, so this is just a reminder that it would probably be good to un-pin and upgrade eventually once the bugs are worked out.

Story points: 2.0
Add a “Post a new topic” button into the sidebar on the group search result page

<p>
My current workflow when posting topics to groups always starts with
searching if the link I am about to submit has already been submitted.
E.g. I search withing ~music for the artist or the song name.  But after
that, I have to either push “Back”, or navigate to the group page again,
as the “~music” in the page header “Search in ~music: Foo My Bar
Tonight” is not a link back to ~music (an issue of its own).  I would
prefer if there was a “Post a new topic” button in the side-bar of the
group search results.
</p>

Story points: 1.0
Remove (or replace) quotes from search view query

When searching there is this text at the top that shows what you searched for:

![image](/uploads/7f059926262637efe30b50b02b291185/image.png)

And now that double quotes have actual meaning because of the search upgrades that came with Postgresql 12, when doing a quoted search it looks a little weird:

![image](/uploads/ccb287d7b40b64448d8b1d9edd847914/image.png)

To avoid confusion about what's actually being searched for, I think it would be good to remove these quotes (or replace them with something else).

Story points: 1.0
Colours mixing when quoting code

<p>
See e.g. <a href="https://tildes.net/~comp/igx/fortnightly_programming_q_a_thread#comment-42sg">this comment</a>.  In
the black theme, both <code>&lt;blockquote&gt;</code> and
<code>&lt;code&gt;</code>/<code>&lt;pre&gt;</code> have the
<code>background-color</code> of <code>#222</code>, which means that
there is no distinction between the quote text and the code or
preformatted text within this quote.  I think that <code>#444</code>
would be a good colour for code inside quotes in the black theme, not
sure about the rest.
</p>

Story points: 1.0
Update marshmallow to 3.0+

marshmallow, which Tildes uses for schema validation and some similar applications, has now released its 3.0 version, after a fairly long RC process. This will require some significant updates to the code, so I've pinned it to 2.x for now but should try to do these updates before too long, since 3.0 seems to have quite a few benefits.

Here's the docs on upgrading: https://marshmallow.readthedocs.io/en/stable/upgrading.html

Story points: 4.0
Add a "demo" page for themes

It would be really nice to have a page where people can easily flip through all the themes and see what different site elements look like with them applied. It could have various "fake" site elements, like what a topic in listings looks like, a little fake comment tree showing how the different types of comments (e.g. exemplary, new) look, and so on, so you can get an overview of the theme in one spot.

This should be fairly straightforward to implement - have a view that creates a `Topic` object, some `Comments` objects and so on (and don't add them to the database session), and then use them all in the template macros that are used to render real versions of those objects. That way the page will keep itself updated whenever any designs change, since it's using exactly the same macros and methods as other pages.

Story points: 2.0
Change comment voting so it doesn't replace the entire comment

Now that we have `<details>` blocks in comments, there can be some strange behavior when voting on a comment that contains them. Since voting results in the entire comment being replaced by intercooler, any `<details>` blocks in it end up getting reset back to their default expanded/collapsed state.

It should be totally fine to just replace the vote button instead of the entire comment. I think originally I was replacing the entire comment because the vote count was inside it, but since it's in the button now there's not really any need to be replacing the whole comment any more.

Story points: 2.0
Add "unfollow" feature, allowing users to turn off notifications for replies to their comments/topics

This would allow users to more effectively disengage from arguments.  It should probably be something disabled by default and only enabled on a case-by-case basis, not a global user setting though, IMO.

edit: Feature also requested again, but for a slightly different reason (avoiding getting spammed on busy topics) -  
https://tildes.net/~tildes/dz7/suggestion_turn_off_reply_notifications_for_a_topic_or_comment_you_made

Story points: 4.0
Incorrect site favicons displayed

Sometimes the incorrect favicon for a website will be displayed:

![image](/uploads/f25700be1c1536752e6e00790ce677d3/image.png)

![image](/uploads/886d3aa146111093a2c411dd546986aa/image.png)

Presumably this is a caching issue, but reloading the page doesn't fix it, and those two screenshots are from two different devices.

Story points: 2.0
Rework views and/or schemas to support webargs 5.0

As mentioned in https://gitlab.com/tildes/tildes/commit/664c6f67904631443bd275dd07f1bbabe1bdcb14, webargs 5.0 no longer sets values for optional arguments: https://github.com/marshmallow-code/webargs/issues/342

The above-linked commit pins webargs' version to avoid this behavior change for the moment, but to be able to upgrade will require some reworking of views/schemas to be able to handle the new approach.

Story points: 4.0
Update annotations to take advantage of delayed evaluation

Python 3.7 includes postponed evaluation of type annotations: https://docs.python.org/3/whatsnew/3.7.html#pep-563-postponed-evaluation-of-annotations

This means that we will no longer need to write annotations as quoted strings when the type is defined later ([example](https://gitlab.com/tildes/tildes/blob/master/tildes/tildes/models/model_query.py#L43)). However, we will have to add a `from __future__ import annotations` to every file where the quoted strings were previously necessary.

This change won't be possible until pyflakes updates to support it, since using it currently still causes a "undefined name" error from Prospector. This is the pull req that will need to be merged first: https://github.com/PyCQA/pyflakes/pull/374

Story points: 2.0
"Set as account default" button disappears after page reload

I searched for "theme" and "Set as account default" but haven't found a bug about this bug. Steps:

1. Go to the settings page.
2. Click on a different theme. The "Set as account default" button is there.
3. Reload the page.
4. I expected the button to still be there, but it isn't. If I switch to another theme and then back, it does appear.

Story points: 2.0
Make the donate page link more prominent on the Tildes homepage.

A more prominent link to the [Donate page](https://docs.tildes.net/donate) is probably going to be necessary at some point.  The only link to it on the site is in the footer, which practically nobody reads (or often even sees).  Adding a more prominent link in the sidebar or even on the header somewhere is probably a good idea...  Even with people potentially developing blindness to it eventually, just for sake of making people aware of the option to donate being available in the first place is worth it, IMO.

Story points: 1.0
Hide topic-comments section when there's no comments

Minor thing but noticed this earlier:

![image](/uploads/0a83ca7a930f448142a7b0c7d7b6b589/image.png)

When there's no comments, there are there 2 borders which are to separate sections like here:

![image](/uploads/230cde6d508e17cde5bbdc61a443e409/image.png)

However it looks weird when there's no comments, so hiding `section.topic-comments` would make it a little neater. It could be done with `display: none;` or a simple `if` check in the template.

Story points: 1.0
Ability for topic creators to change their titles

With the addition of the [first stage of community moderators](https://tildes.net/~tildes.official/53r/users_can_now_be_manually_granted_permissions_to_re_tag_topics_move_them_between_groups_and_edit), a topic log now exists that tracks changes to topics as made by those with permission to do so. It'd be nice to have this be extended to topic creators in being able to edit their titles after submission. Both the log and the higher-permission users would stand in to prevent bait-and-switch style manipulation.

Story points: 1.0
Users should be able to view their 2FA backup codes (and possibly generate new ones)

Just came to mind while I was writing the announcement about 2FA - there should be a way for users to view their backup codes after 2FA is enabled, in case they didn't initially store them. It may also be nice to have the ability to generate more, though people can always just disable and re-enable it to do that.

Viewing them will need to require a 2FA check, otherwise someone with access to the logged-in account would just be able to take a backup code and bypass/disable 2FA (similar to why disabling 2FA requires it).

Story points: 2.0