Reorganization of issues

[tesshucom]

It is difficult to use it effectively because the classification of issues is not maintained. Therefore, it will be organized.

• Relabel to make it easier to find related things
• The one with the label has priority. The one without the label is later.

---

The label of spring-framework is referenced. It is categorized by the prefix of for, in, status, and type. It doesn't need to be changed significantly and can be used with Airsonic with a few changes.

label	discription
for: backport-to-x.x.x	Designates an issue for backport to x.x.x
for: external-project	Needs a fix in external project
for: merge-with-amendments	Needs some changes when we merge
for: stackoverflow	A question that's better suited to stackoverflow.com
for: team-attention	An issue we need to discuss as a team to make progress
in: core	Issues in core modules (aop, beans, core, context, expression)
in: data	Issues in data modules (jdbc, orm, oxm, tx)
in: messaging	Issues in messaging modules (jms, messaging)
in: test	Issues in the test module
in: web	Issues in web modules (web, webmvc, webflux, websocket)
status: backported	An issue that has been backported to maintenance branches
status: blocked	An issue that's blocked on an external project change
status: bulk-closed	An outdated, unresolved issue that's closed in bulk as part of a cleaning process
status: declined	A suggestion or change that we don't feel we should currently apply
status: duplicate	A duplicate of another issue
status: feedback-provided	Feedback has been provided
status: feedback-reminder	We've sent a reminder that we need additional information before we can continue
status: ideal-for-contribution	An issue that a contributor can help us with
status: invalid	An issue that we don't feel is valid
status: pending-design-work	Needs design work before any code can be developed
status: superseded	An issue that has been superseded by another
status: waiting-for-feedback	We need additional information before we can continue
status: waiting-for-triage	An issue we've not yet triaged or decided on
type: backport	An issue that is a backport of another issue to a maintenance branch
type: blocker	An issue that is blocking us from releasing
type: bug	A general bug
type: dependency-upgrade	A dependency upgrade
type: documentation	A documentation task
type: enhancement	A general enhancement
type: regression	A bug that is also a regression
type: task	A general task

https://github.com/spring-projects/spring-framework/labels

At least because it has a better perspective than the previous Airsonic. I will start making changes as long as there is no objection. How about? (If you wait for a response from someone who has not responded recently, it will never end.)

The precautions for replacement are classified and explained below.

[tesshucom]

Replace with new label

The following items may be exchanged as they are. Naturally classified by prefix.

after	before
for: backport-to-x.x.x	release
for: team-attention	discuss, organisation
status: duplicate	duplicate
status: ideal-for-contribution	good first issue, patches-welcome
status: pending-design-work	breaking change
status: waiting-for-feedback	research needed
type: documentation	documentation
type: enhancement	enhancement
type: regression	regression

[jooola]

neverstale label is used to prevent the stalebot from closing issues, this needs to be taken into count.

[tesshucom]

neverstale label is used to prevent the stalebot from closing issues, this needs to be taken into count.

OK. Thank you!

[tesshucom]

reclassified to "in"

before

frontend backend browser specific build database feature: docker REST API search testsuite translations playback

The "in" of spring will be replaced with one that is compatible with Airsonic. This category is most often used on Airsonic labels. Therefore, it may be more helpful to add more items.

For example, transcoding, podcasts, web players, etc. should have separate categories.

[tesshucom]

Use as is without changing

It should not be touched as it is used by the bot.

before

dependencies stale neverstale

[tesshucom]

Add Airsonic-specific items

before	Add to
can't reproduce	Add new item to "staus"
feature request	Add new item to "type"
question	Add new item to "type"

Not in Spring. In the case of Airsonic, it would be a little trouble without this.

[tesshucom]

Probably not necessary?

before

workaround non trivial crash critical low priority

It seems that it is appropriate to properly express in other items. It's too abstract to understand the meaning. It may include subjectivity and is not suitable for later use as a key for search classification.

Significance can be determined by customary immediate response and inclusion in the master, or by milestone.

[jooola]

Use as is without changing It should not be touched as it is used by the bot.

Actually no, it can be changed, but bots configurations needs to be changed as well, or you will end up with a bot mess like an avalanche of bot emails.

See https://github.com/airsonic/airsonic/blob/master/.github/stale.yml

I think the dependabot can use a local yaml configuration, it just needs to be created.

See https://dependabot.com/docs/config-file/

[tesshucom]

OK. I will check the contents so that they can be used effectively.

[tesshucom]

Isn't it better to use "Projects" in addition to Label?

security

Security does not exist in the label, but I think that it is suitable to add it to the "Projects" in addition to the usual classification of for, in, status, and type.

usability, code quality, performance, Hacktoberfest

These are a bit too abstract to use for classification. At least we need to relabel as for, in, status, and type.

"Projects" already has the following items:

• Modernise and cleanup airsonic
• Improve the web interface

Most of them can be classified in this? The term performance is generally treated as an incident, or a bug if performance requirements cannot be met. It seems that many other issues mention cleanup.

There are 38 existing items, so they are all included in any of the proposed classifications above. Focusing on the convenience of being easy to find later. If you have any feedback!

[eharris]

I started this post off listing things that I noticed that didn't seem to apply or had other discrepancies, but I soon gave up because it was too time consuming to try to reconcile the back-and-forth discussion down to exactly what tags (and their replacements) are being proposed.

Since this is a discussion/proposal ticket, I suggest you provide (and maintain) a complete and definitive list of the "before" and "after" and "reasoning" for every Airsonic-specific label (including new and removed ones) being proposed. Once that is done, it will be much easier to see what deficiencies might be remaining to be addressed.

[tesshucom]

OK. I made the same attempt as you, and gave up. Think of the wreckage as "Replace with new label". That's the only items that can be transferred almost as they are.

It may be a pain to hear, but Airsonic's current issus management is not that high quality. This means that it is difficult to move to general tracking with simple work. (That's why it's a meaningful job)

Most require reassignment (Rather, the classification has not even begun. We will now start a classification that was previously ignored).

That said, I don't like complete destruction. The group at the bottom is the one that seems somewhat inadequate. They are proposing if they may be redistributed to the project.

Or, if those categories need to be expressed externally as Airsonic's mainly concerns, we can define new ones is "Projects". (However, some of them had been probably improvised or set by people who are new to task classification, rather than called categories.)

---

For the full migration list, either is fine, if it's a consensus that you need it, you should do so. I think that... If the original issue management is high quality and reliable, it is definitely worth it. Otherwise it's a waste of time and just a blocker. We ask other members for their views.

[fxthomas]

This sounds good, :+1: for doing that!

A few comments:

• in: messaging might be a bit useless for Airsonic?
• I would try to transform some of the current labels (playback, docker, rest) into in: xxx.

[tesshucom]

We may leave the in: message. Exception message and translation has only not been treated carefully until now. There seems to be an update that was originally supposed to be managed.(This is intuitive) Also, I do not know the details yet, but it may be possible to work with #1589. The decision may be a little later.

in: xxx needs to be reconfigured. There may be a JDK, a startup, etc. It should be possible to improve this by repeating the assignment process several times. While it is a technically relevant classification, it is also important not to increase the number of categories too much. (Although it contradicts)

For example, the image below :

Compound search is easy if it is classified correctly, right? (But if you divide it too much, the list will be difficult to use!)

It's hard to decide everything at once, but we can brush up gradually.

It is the impression that I actually tried with a clone. It is faster to move our hands than to think with our head. It's not an irreversible change and at least better than now. And it is essentially a task that requires regular maintenance.

Base can start in Spring style. Some adjustments are needed. Especially "in". Other than that, it is useless to incorporate various essences too much. It has already been proven to be invalid.

[fxthomas]

Ah, in: message was about translations? That wasn't how i read it, I thought it was related to another component. Might be better to replace it by in: translations then?

Other than that let's go for it, feel free to do it any time!

[tesshucom]

OK. I'm not stuck with SpringStyle's in:, and I think it should be optimized. There may be many in: created at first, but think of it as a transitional period. I think it is good to classify and use them, and to think about the right classification while considering the amount. Probably somewhere there is a level that users and bug trackers are generally satisfied with.

[fxthomas]

Nice, thank you! It looks clean at first glance, I'll put suggestions if I have them here.

[tesshucom]

Maintenance query sample.

A label that is always given

Issue type

issues are classified into one of the following types.

prefix	name	"In" required
for	team-attention
type	regression	〇
	bug	〇
	documentation
	enhancement	〇
	question	〇
	request	〇
	tips	〇
	task

Uncategorized issues

in:

Below issues with the prefix type are always labeled in:.

label	in:
type: regression	Uncategorized
type: bug	Uncategorized
type: enhancement	Uncategorized
type: question	Uncategorized
type: request	Uncategorized
type: tips	Uncategorized

status:

The following prefix type issues always have one of the statuses:

		type
		regression	bug	question	request
status	waiting-for-feedback	〇	〇	〇	〇
	feedback-provided	〇	〇	〇	〇
	can't reproduce	〇	〇
	waiting-for-triage				〇
	duplicate	〇	〇	〇	〇
	superseded	〇	〇	〇	〇
		Uncategorized	Uncategorized	Uncategorized	Uncategorized

---

• "Issues" for which the implementer has been decided do not need to be tracked much even if they are not classified very deeply. We just need to know that it's under enhancement.
• The usage of enhancement was very vague. It's open source, so we can't start without strong implementers.I think it makes sense to have a core implementer, a maintainer who agrees with the design and implementation, and mark a title where no concerns have been expressed. That is, enhancement should be added to titles that are likely to be merged into master in the future by improving quality. That's what external users and developers want to know.
• Most "enhancement" so far has been equivalent to a request. Even the maintainer's issues should be marked as a request if it doesn't result in an enhancement.
• The pull request is also a pull request in the initial state. It can be changed to enhancement if the maintainer agrees and there is no opposition.
• It seems that external developers often expressed their willingness to implement. Some implementors have a quiet personality while having great ability. For attractive offers, it's best to actively ask for PR and mark the enhancement :blush:
• Those marked as enhancements can be considered for assignment to milestones. Unfortunately, it's not a project with rewards. If you can't implement even the best suggestions, you can't triage. Labeling the enhancements with no promise is confusing and stagnant, so it's a good idea to make a distinction.
• This time I'm labeling in a hurry, so errors and uncorrected ones may be included. Please change the label when you notice it.

[jooola]

As little side note, I recommend using the embed GitHub auto label tool that comes with issue templates.

You can auto label new issue based on the kind of issue someone created (bug/feature request/...).

Here is the doc: https://help.github.com/en/github/building-a-strong-community/configuring-issue-templates-for-your-repository

Here is an example: https://github.com/directus/gatsby-source/tree/master/.github/ISSUE_TEMPLATE

[tesshucom]

That's good! I was hoping that I could do it. I will check the content and reflect it.

In fact, I find it difficult to operate like a full-scale management product. (Functional and personnel) Still, you may be able to do something similar to that in part.

[tesshucom]

Summary example. There is also the idea of ​​creating and pin such a link.

"pin" in the upper right of issues. With some nifty message ... :persevere: I would like to ask someone who is good at English.

---

Main opened issues recently updated

regression	bug	question	request
:red_circle: :white_circle:	:red_circle: :white_circle:	:red_circle: :white_circle:	:red_circle: :white_circle:

Details by "in"

		type
		regression	bug	question	request
in	authentication	:red_circle: :white_circle:	:red_circle: :white_circle:	:red_circle: :white_circle:	:red_circle: :white_circle:
	build	:red_circle: :white_circle:	:red_circle: :white_circle:	:red_circle: :white_circle:	:red_circle: :white_circle:
	cover art	:red_circle: :white_circle:	:red_circle: :white_circle:	:red_circle: :white_circle:	:red_circle: :white_circle:
	data-scan	:red_circle: :white_circle:	:red_circle: :white_circle:	:red_circle: :white_circle:	:red_circle: :white_circle:
	data	:red_circle: :white_circle:	:red_circle: :white_circle:	:red_circle: :white_circle:	:red_circle: :white_circle:
	dlna/sonos	:red_circle: :white_circle:	:red_circle: :white_circle:	:red_circle: :white_circle:	:red_circle: :white_circle:
	docker	:red_circle: :white_circle:	:red_circle: :white_circle:	:red_circle: :white_circle:	:red_circle: :white_circle:
	external cooperation	:red_circle: :white_circle:	:red_circle: :white_circle:	:red_circle: :white_circle:	:red_circle: :white_circle:
	jdk	:red_circle: :white_circle:	:red_circle: :white_circle:	:red_circle: :white_circle:	:red_circle: :white_circle:
	playlists	:red_circle: :white_circle:	:red_circle: :white_circle:	:red_circle: :white_circle:	:red_circle: :white_circle:
	podcast/radio	:red_circle: :white_circle:	:red_circle: :white_circle:	:red_circle: :white_circle:	:red_circle: :white_circle:
	rest	:red_circle: :white_circle:	:red_circle: :white_circle:	:red_circle: :white_circle:	:red_circle: :white_circle:
	search/sort	:red_circle: :white_circle:	:red_circle: :white_circle:	:red_circle: :white_circle:	:red_circle: :white_circle:
	smart playlists	:red_circle: :white_circle:	:red_circle: :white_circle:	:red_circle: :white_circle:	:red_circle: :white_circle:
	tagger	:red_circle: :white_circle:	:red_circle: :white_circle:	:red_circle: :white_circle:	:red_circle: :white_circle:
	test	:red_circle: :white_circle:	:red_circle: :white_circle:	:red_circle: :white_circle:	:red_circle: :white_circle:
	transcoding	:red_circle: :white_circle:	:red_circle: :white_circle:	:red_circle: :white_circle:	:red_circle: :white_circle:
	translations	:red_circle: :white_circle:	:red_circle: :white_circle:	:red_circle: :white_circle:	:red_circle: :white_circle:
	UNKNOWN-backend	:red_circle: :white_circle:	:red_circle: :white_circle:	:red_circle: :white_circle:	:red_circle: :white_circle:
	UNKNOWN-frontend	:red_circle: :white_circle:	:red_circle: :white_circle:	:red_circle: :white_circle:	:red_circle: :white_circle:
	web-playback	:red_circle: :white_circle:	:red_circle: :white_circle:	:red_circle: :white_circle:	:red_circle: :white_circle:
	web	:red_circle: :white_circle:	:red_circle: :white_circle:	:red_circle: :white_circle:	:red_circle: :white_circle:

---

Frequently used links

• Recently updated pull request (Excluding Bot)
• dependency-upgrade
• documentation
• team-attention

[fxthomas]

Summary example. There is also the idea of ​​creating and pin such a link.

I assume this will not be automatically updated? In any case I like the idea, might help with searching issues!

[tesshucom]

The link is a Github URL query. So if the issue status changes, it will be reflected in the appropriate classification.

Note that the displayed results are sorted in recent ascending order. "Recently posted by someone" and "Recently modified by someone" are displayed above.

It can be used effectively with the correction of #1707.

The table is not automatically possible ... I wrote a nice program.:disappointed: If the "in" classification doesn't change much, you can use it fixed.

[tesshucom]

@airsonic/maintainers

The following labels have moved to https://github.com/airsonic/airsonic/projects. You can easily browse by the reference function of Github.

• Hacktobefest
• usability
• quality
• performance
• workaround
• trivial
• low priority

This does not mean moving to the so-called trash. I think it is meaningful as a classification at the time it was created. Therefore I kept it so that I could refer to the original. However, a few years ago... the situation has changed dramatically since the days when it was easy to unify the goals right after the subsonic branch. The current situation is a mix of old bugs, recent bugs and many requests. As you can see. If we manage issues in the long run, we can make small changes to a better management method regularly. Keep in mind that the current method may not be the best, but such a transformation may be necessary.

@muff1nman

Where is airsonic heading? It's been controlled by fxthomas for a while, so it's quite a step forward. His work was more than just coding and reviewing. Some complained about speed, but I don't think so at all. However, it is currently stagnant. It has some fatal bugs and the master build is dead. I can do a little if I need help, but I don't think changing the master arbitrarily at one's discretion is desired. The triage and merge criteria were previously ambiguous, and everything would stop working unless there were at least multiple active members. I support a development style that does not force anything. But now it seems little too unclear.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. Thank you for your contributions.