search

opensearch-project / .github

Provides templates and resources for other OpenSearch project repositories.
Apache License 2.0
28 stars 71 forks source link

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

Closed macohen closed 1 year ago

macohen commented 1 year ago

What are you proposing?

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

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 commented 1 year ago

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 commented 1 year ago

@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 commented 1 year ago

@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 commented 1 year ago

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

peternied commented 1 year ago

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

macohen commented 1 year ago

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.