How to expedite critical issues?

With that logic could we not ditch the feature request label? I’m just not sure what the purpose is of having both labels - maybe it indicates the level of work required? I’ll give in on that if you disagree but could we at least name it ‘enhancement request’ so it implies the same intent as ‘feature request’?

Also with the focus on issues here are you suggesting we stop labelling PRs, I would support this as I think it probably serves little purpose except for if we set up automated changelogs but I think it’s important to know - if we do continue labelling PRs we would need to add new labels or adjust naming & descriptions of existing ones (in your proposal).

I suggest we make a post under the governance category with the details of your proposal and a poll (like I’ve done for the contributor votes). We don’t have a specific policy but I think we should have at least a majority with team members.

I’m not sure you can post on the gov category at the moment but I could change that. (edit: you can post)

Once we post a poll we cannot change anything or existing votes would become invalid as the underlying proposal changed. I think we’d need a fixed timeframe for discussions and amendments (7 days?) and a closing poll after that. Do we have a way to actively reach out to all team members and invite them to vote? If not, maybe the timeframe should be even 14 days.

Since we don’t have a change scope criteria, the 2 labels sort of do that: feature requests would usually be larger in scope and more complex, requiring more fundamental feedback from team members due to higher impact and relation to product strategy/roadmap. Enhancements would usually be smaller in scope and may not require as much attention or discussion - only generally speaking of course. It may give team members an easy way to identify changes of larger scope and weigh in.

That’s a good question. PR labelling is not addressed here. The only purpose I can think of labeling a PR is to automate the change log creation. That requires some additional rules on how to label PRs, eg. to ensure we don’t see internal changes like testing related in the change log. I am not familiar with how automated change log generation currently works - who could we ask to join the discussion here?

Sounds good, nearly all the active contributors are in the slack team channel, I can try and reach out to anyone who isn’t. I think 7 days might be a little short, as often people are away or busy.

Makes sense, so keep both but do you object to calling it an ‘enhancement request’? In my mind if we stick with ‘enhancement’ we may as well go with ‘feature’ as well.

Edit: The only other reason to go with one label instead of two is that you can have a certain issue template have specific labels added by default so we could have issues created with the feature request template automatically labeled as such - which could save some time?

I think if you are suggesting we remove all non-specified labels we have to decide on this. I would say scrap PR labelling, there are currently no repos with automated changelogs and we can add labels like PR type -> bug fix etc if it ever happens. PRs are labelled quite infrequently anyway.

As far as I know I’m the only team member who has looked at automating them, I did try out a system with the iOS SDK but I wasn’t too happy with it and didn’t have the time to get the team onboard with it.

Also can I keep the labels on the docs repo (for issues and PRs) - the ‘waiting for release’ label I use especially helps to speed up my workflow.

Sounds good. It would be nice to have a dedicated channel for this, maybe via Github or the Community Forum rather than Slack, to better accessibility. Something like a channel people can subscribe to and only the core team has the rights to reach out. That would be nice to have for Parse Team member and for the whole community as well, when it comes to roadmaps, etc.

I actually meant to rename it, sorry, done now.

I don’t think we should do automatic labeling based on template. The author may request a feature that already exist, then we have a wrong-labelled issue. I think if we label manually (for the few issues that we have) we can at least be sure someone from the team looked at it. This also helps to identify critical issues and maintains “trust” in the labels.

Having said that, I would also prefer 1 label instead of 2 for simplicity, but I also find it practical to scan through the issues and see approximately whether its a new feature or an improvement of an existing one. I think the open discussion with all members should clarify this.

It’s easier if we separate the two issues (new labels vs. automatic change log) so I’d agree to script PR labeling for now. I like the idea though, we should look into it at some point, maybe once the new labels here are established.

Thanks for putting the work into this, I think we’re good to present this to the rest of the team now.

Yes I agree, but the forum actually has worse uptake amongst team members than the slack - although I have been inviting people to join recently. Github is most accessible but is also least equipped for that type of thing.

Actually don’t like it that much for its length, “enhancement request” or “feature request”. I think a label should be one word only from a human standpoint to quickly scan it visually. We also have a “bug” label and don’t call it “bug fix request”. The labels are mostly used by non-first time users. I had another look at labeling in other repos and it seems to be common to use “feature” and “improvement/enhancement/optimization”.

For example:

Would you agree on removing the “request” from both?

Yes, go with that!!!

Removed “request”. I have also added the suggestion for a bot that adds “up for grabs” to “feature” and “enhancement” after n days of inactivity.

I like that. Do you want to create a topic for team feedback then?

If there are no objections / any objections are resolved in the feedback period I don’t think it is necessary to have a vote.

In which channel, governance?

Yeah, I’ll share with the team once you’re happy.

1 Like

@Tom If you have any feedback on Harmonize GitHub labels and usage please let me know (especially the last paragraph), otherwise please feel free to publish on Slack / share with the team.

1 Like