[PROPOSAL] Clarify Issue Types and "Last Call for Comments"

[macohen]

What are you proposing?

We have Feature Requests and Feature Proposals documented in CONTRIBUTING.md, but we also have PROPOSALS, RFCs, FEATURE BRIEFs, BUGS.

• Could we standardize on the types of issues?
  • BUG: an unexpected result from some operation in OpenSearch that SEEMS like a bug (meaning something broken)
  • Feature Request: I have an idea for new functionality, but don't have a solution. I'd like to collaborate on one or just put it out there for someone else to build.
  • Collapse these into "Feature Proposal" (clearest definition I see).
    • RFC: Request for Comments. - I have an idea for some implementation of a problem I have, but really want to hear from the community before doing too much.
    • PROPOSAL: is this different than RFC?
    • Feature Proposal: I have an idea for a feature and maybe a solution. I don't know necessarily how to build this and want to understand what others think (is this too subtle a difference from an RFC? Should this be rolled up?)
      * Are there others?
• The GH issue should be used for commenting/discussion of the initial design. The forum should be used for long lived discussions/questions of the feature.
• For an RFC/Proposal/Feature Proposal, let's standardize on addressing how long the issue will stay open (could be a field in the issue template and could vary on a case by case basis) and post a reminder that the issue will be closed at least a week ahead?

What users have asked for this feature?

@mashah - "Yes, we’re not sure both on where and how to get involved. It would be great 1/ we could put the discussion and comments for RFCs in one place (right now it seems to be distributed between forums and GitHub). 2/ Have a protocol for agreeing on and closing RFCs. A simple “last call for comments” and aiming to “close on date XX” would be helpful. 3/ perhaps have a place where we know the experimental items are ? (Again, I might have missed it.)"
https://opensearch.slack.com/archives/C04UM4D6XN2/p1685306611855109

[dblock]

The current status of templates used/recommended across repos in opensearch-project is in https://github.com/opensearch-project/.github/tree/main/.github/ISSUE_TEMPLATE. Do you mean to say that there are inconsistencies in the language in CONTRIBUTING? If so, yes, please fix.

As of now in .github, a feature request is a kind of proposal (a feature proposal). An RFC = proposal. You can propose to change some/all of that of course, but please be mindful that it has been propagated across 100 repos, so YMMV in terms of adoption.

I dislike the idea of putting comments and RFCs in "one place". In my opinion that place is near the source-code because it's an open-source project and code represent the current state. Code in this project is in 90+ repos, I wouldn't want to have to go to "one place" to find all proposals about the k-nn plugin vs. opensearch-java client.

If you or @mashah want to contribute a change to any of the templates to add a "close on date XX" proposal, go for it!

[peternied]

@macohen I think the issue types are pretty clear, what do you want to accomplish with standardizing them? It might be easier to see this with a PR to modify the issue template(s) that you'd like to see changed.

[macohen]

@peternied what I think I realized here is that these issue templates are pretty good and they have been updated since one of the repos I work in was created; I may have missed something, but it might be great to create issues in every repo when any .github files that could apply everywhere are updated. It's always up to the admins if the change is required (like the recently completed maintainer cleanup). If it's not required the repo maintainers can decide whether to take the change or not and close the issue.

I do think that we should consider abandoning the term RFC if Proposal is the right thing for consistency in the project. I'm going to start doing that in my own issues...

[peternied]

@macohen When you perform the 'sync', would you mind writing that process up and creating a PR in this repo?

There are two issues around automating these processes, one [1] created by @elfisher to synchronize the issue templates and another issue for sync'ing workflow files [2].

• [1] Standardize and monitor organizational issue templates #9
• [2] [FEATURE] OpenSearch-Project workflow manager #113

[peternied]

@macohen the original proposal seems relatively complete, how would you like to use this issue or would you rather close it out?

[macohen]

Closing it out. It seems the answer is to create a process to sync .github project changes across the org. I'll track the other issues regarding automation. Thanks.