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.
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â.
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.
@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.