Collecting Template System using GitHub Action

[ymw0407]

n addition, although Issue Templates and templates from various well-known open sources are now directly put into the DB, we want to use GitHub Action to create a structure that can be put into the DB if the Issue is normally closed by the maintainer.
또한, 지금은 Issue Template 및 여러 유명 오픈소스들의 template을 직접 DB에 집어넣고 있지만, GitHub Action을 활용하여 Issue가 maintainer에 의해 정상적으로 closed 된다면, DB에 넣을 수 있는 구조를 만들고자 한다.

I hope a lot of opinions from the maintenance people in this regard.
It's time to think about how to collect templates rather than the current hand-in-hand method.
이에 관하여 Maintainer들의 많은 의견을 바란다.
현재의 손수 넣는 방식보단 어떤 식으로 template들을 모으는게 나을지에 대해서 고민해볼 시간이다.

@AgainIoT/development-team

[ymw0407]

This Thread is related to Issue #36

[sinji2102]

Rather than automatically adding an issue when closed, the structure that allows users to add templates themselves seems better. If added after closed, it seems difficult to manage if a user who has not disclosed it later wants to disclose it or vice versa. In addition, when users add templates themselves, they think that they can use MyPage more abundantly than they are now by allowing them to be managed by the user's MyPage.

Issue가 closed 될 경우 자동으로 추가되는 방식보단, 사용자가 Template를 직접 추가할 수 있는 구조가 더 좋아보입니다. closed 이후 추가될 경우, 후에 공개하지 않은 사용자가 공개하고 싶어질 경우 혹은 그 반대의 경우를 관리하기 어려워 보입니다. 또한, 사용자가 직접 Template을 추가할 경우 사용자의 MyPage에서 관리하도록 하여 현재보다 MyPage를 풍성하게 사용할 수 있다고 생각합니다.

[ymw0407]

Oh, that part seems to be a different issue.
In the case of this comment, I think it's about how to collect templates from Open-Set-Go users. First of all, what I'm talking about is when I collect several famous open-source projects, not user templates.
아 그 부분은 다른 이슈에 해당하는 것 같습니다.
해당 커멘트에서 얘기하는 부분과 같은 경우에는, Open-Set-Go 사용자들의 template을 어떤식으로 수집할지에 대한 이야기인 것 같습니다. 우선 제가 이야기한 부분은 사용자들의 template이 아니라 여러 유명 오픈소스 프로젝트들을 수집할 때의 이야기입니다.

I think it would be good to talk about it by adding one more Discussion.
First of all, the policy that we are thinking about is that when the user presses Get Started through Open-Set-Go, if the template is produced through Open-Set-Go in a modal window, it will be used as a template for Open-Set-Go, and when the user presses Complete to create a repository, the data will be stored in the DB to make a template that can be used by Open-Set-Go.
해당 커멘트에서 이야기하는 내용은 Discussion을 하나 더 추가하여 이야기해보면 좋을 것 같습니다.
우선 여기서 간단하게 이야기하면, 현재 생각하고 있는 정책으로는 사용자가 Open-Set-Go를 통해서 Get Started를 눌렀을때 modal창으로 Open-Set-Go를 통해서 Template을 제작하게 된다면, Open-Set-Go의 Template으로 활용될 것이다라는 안내창을 띄우고, 사용자가 Complete를 눌러서 Repository를 만드는 시점에 해당 데이터를 DB에 저장하여 Open-Set-Go에서 활용할 수 있는 Template으로 만들 생각입니다.

[ymw0407]

We've found a problem now. Previously, when an issue is closed, if it is triggered, it is put in MongoDB. However, the assumption itself thought that the process of Issue Close should be authorized. In this situation, assuming that an outsider puts strange data into the DB, it seems to be a structure that the administrator cannot filter. That's why we need to think about other options.
현재 문제점을 하나 발견하였습니다. 기존에 이슈가 Close 되면 트리거가 되면 MongoDB에 넣어준다라는 식으로 진행을 했었습니다. 하지만, 이 가정 자체가 Issue Close하는 과정이 권한이 있어야된다고 생각했습니다. 지금 상황에서는 외부인이 이상한 데이터를 DB에 넣는다고 가정했을때 관리자가 필터링할 수 없는 구조인것 같습니다. 그렇기 때문에 다른 방안을 좀 더 생각해봐야할 것 같습니다.

[ymw0407]

The point here is that users (open-source contributors) can easily propose a famous open-source template, but the filtering process itself should be a structure that can be easily done by the maintainer and cannot be touched by an outsider.
여기서 중점은 사용자들(오픈소스 기여자들)이 쉽게 유명 오픈소스의 template에 대해서 제안할 수 있지만, 필터링의 과정 자체는 maintainer가 쉽게 할 수 있고, 외부인이 건드릴 수 없는 구조여야 한다는 점입니다.