Enable GitHub issues

[slawekjaranowski]

I hope that we not need an issues migration for this project - it is simply current state of site.

We have 69 issues opened now:
https://issues.apache.org/jira/projects/MNGSITE

After it we can create a pined issue with information and link to JIRA

Next steps after merge:

• block for creating new issues in JIRA - existing issues should be possible to comments, closing and so on

[Bukama]

According the removal of the JIRA link: When not migrating issues, shall we keep the link for some time with the note that it's read only (assuming that JIRA issue creation will be disabled as discussed on mailing list)?

Aside from this: non binding approval

[slawekjaranowski]

According the removal of the JIRA link: When not migrating issues, shall we keep the link for some time with the note that it's read only (assuming that JIRA issue creation will be disabled as discussed on mailing list)?

I will add an pined issue with information and template which also contain JIRA link

[slawekjaranowski]

Issues template added.

[Bukama]

a bug to the bug maybe?
I would also point out to specify the expected behavior, not only a description of the "seen" behavior.

[slawekjaranowski]

ok there is next proposition

[slawekjaranowski]

as it is documentation project I would not to complicate the bug form

[slawekjaranowski]

Issue page will be look like:

bug report:

and

[Bukama]

Thanks for the preview to get a better idea how it will look. My thoughts below.

Issue page will be look like:

General:
I link that you thank people to take the time to fill out the forms - we value their time and effort!

The part "and answer" part of "Please ask and answer on the mailing list" sounds strange, like "Please ask your question on the mailing list - oh and answer it by yourself too please, so we don't have to - thanks!" 🙈

Issue page:
I think you want to create a template, easily reuseable by other repositories, but as were are in the context of a website, maybe we should rephrase "File a bug report" to something containing also "mistake" or "error" aiming at outdated or wrong information on the website (in contrast to a technical bug, like broken links etc.). But maybe that's just me focusing on texts for non/less IT people (what I write a lot at work).

Bug report:
"An/Opening issue is not needed..."

In site's context I think this is okay, but I don't like it in general as it may result in situations where people try fixing something which is either not wrong or do it in a wrong way. What I want to say with this: I like to discuss / agree on bugs before fixing them (more true in open source projects than at my work where all have good knowledge of the code and system).

The title and description should be a required field.

Improvement:
The title and description should be a required field.

[elharo]

Is "with fixing" correct? It sounds off.

[slawekjaranowski]

My idea is to not required issue creating if someone has a plan to make a PR in the same time.

Big or more complicated planned change should have an issue to first discuss before starting implementation.

So how to say in simple way?

[elharo]

"Simple fixes in single PRs do not require issues."

That said, some (not all) simple fixes do require issues. For instance, a one-line change that fixes a really serious bug should have an issue to show up in the release notes, but a one line change that corrects a spelling error in a comment should not.

[slawekjaranowski]

It is a documentation site ... so we don't have a release notes here - it is current state only.

[elharo]

Is massage correct? That's a strange ID for this project. Was perhaps message meant?

[slawekjaranowski]

id is a technical required field - must be unique

https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/syntax-for-githubs-form-schema#keys

[elharo]

I'm unclear on what happens to old issues under this proposal. Are they now available in github or not? Or are some available and some not? And of so which ones?

[slawekjaranowski]

I'm unclear on what happens to old issues under this proposal. Are they now available in github or not? Or are some available and some not? And of so which ones?

My proposition is to not migrate as we have a link to old jira in templates and we can continue work on in.

We should only block creating new issues in JIRA.