How to expedite critical issues?

GitHub 🐙
#15

Hi, guys. Sorry for the delay. I think it makes a lot of sense to refactor our labels. We could also try to re-label and clean the current issues. We can then try to create a board in GitHub at least with the most critical bugs so we can have a clear vision of what it is the most important thing to do next. Overall I agree with your ideas and suggestions in this thread. I think we can summarize everything in the Governance repo? Then we can just make it live and discuss possible improvements when running the process.

#16

Absolutely that makes sense.

For bugs I can see that easily, because they are triaged and assigned a severity level. For feature requests I wouldn’t know how to prioritize them without polling the community.

I think we should invite all members of the team for feedback before publishing them. It’s a change that impacts virtually everyone and being a community project, we should maintain the team culture by including it in such decisions. (The StackOverflow moderator community gave a warning example over the last months of how important it is to consider team dynamics in a community of volunteers.)

#17

Nice. I think it makes sense. Let’s do that. We can draft a PR to the Governance repository and/or Create a new post with a summary of this thread. Then we can invite the others to comment and agree/disagree. @Tom is probably the best one to setup that.

1 Like
#18

After having another look over the proposal I have a few final thoughts…

  1. Not sure about going from ‘feature request’ to ‘feature’, I find that request describes the intent of the author well. Is the idea that ‘feature’ can then encompass tracking issues (for feature PRs) and discussions where the author intents to make a PR? If that is the case could we have two (or more!) separate labels or a couple sub-labels so maybe feature & request or feature & tracking… or something else?

  2. question & troubleshooting - I would push back against ‘trying to help there’ - I think the more we do that the more people expect help on GitHub - but I think it’s ok if you can provide a quick tip/solution to the author, I’m also hoping with some improvement in the issue templates we can decrease this load.

I’m not sure that there is an important distinction to be made here for issues. For me if it’s a request then feature request is a sufficient label whether its a small improvement or a significant new feature. Maybe we could use something more generic like ‘change request’ or ‘work request’ - feel free to come up with something better.

#19

Good point, changed.

I would suggest we start with a basic set and add more distinct “feature” labels as needed.

True that, I will remove “try to help here” from the description and add your “quick tip/solution to the author” and for more in depth issues refer to SO / community forum.

Then maybe the current label “enhancement” and its description is fine. I guess whatever change it is, it could always be considered an “enhancement” in some form, even if it’s cleaning up the code base by removing an unused / obsolete feature. I won’t change anything here, unless there is a suggestion.

#20

@Tom do we have a process to collect feedback from the Parse team regarding the change of labels?

#21

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).

#22

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)

#23

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?

#24

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.

#25

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.

#26

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.

#27

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.

#28

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?

#29

Yes, go with that!!!

#30

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.

#31

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.

#32

In which channel, governance?

#33

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

1 Like
#34

@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