-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Establishing a Process to Prevent Duplication in LWKD Articles #250
Comments
Hey @fykaa ! Is this open for all ? |
This only really applies to KEPs. PRs are current for the week, so there's no possibility of duplication. We avoid duplication of developer news just by checking last week's issue, because again, they're very time-bound. So, +1 to having a log somewhere of which KEPs have been featured. |
Hey, @professorabhay ! This issue is a "process issue" for existing LWKD contributors. It's not a good place to get started. |
What I generally do for avoiding repetition while writing KEP of the Week is search for the KEP number globally in the repo and check if it has been featured in KEP of the Week in any previous issue. I have a general idea of KEPs I've written before, but I make sure to do this before I start writing so that I can be sure no other contributor who has written KEP of the Week has already written about the KEP I'm choosing for the week. This works for me now since the list is small. Documenting all of the features KEPs would really help in the longer run and make things easier. |
An idea would be to basically go through the articles with a script and try to regex the KEP and featured PR's and maintain a list. |
So what I recently started doing is simply search the KEP no./ PR no. / others in the LWKD repo |
The Kubernetes project currently lacks enough contributors to adequately respond to all issues. This bot triages un-triaged issues according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
I've noticed that when working on KEPs, merge requests, and featured pull requests for LWKD, we often run into the issue of duplicating efforts because it's challenging to keep track of what's already been discussed in our LWKD articles. To streamline our workflow and improve efficiency, I propose we establish a process to recognize and track these discussions.
Objective:
The main goal is to prevent the duplication of topics in forthcoming articles by keeping a record of what has already been covered in LWKD.
Suggested Approach:
Create a central document or database where we can log and categorize KEPs, merge requests, or featured pull requests that have been discussed in LWKD.
Before starting work on a particular topic, contributors should check this document to ensure it hasn't been covered recently.
If a topic has already been discussed, we can provide links to the relevant LWKD articles for reference.
Benefits:
Discussion:
Please share your thoughts and suggestions on how to implement this process effectively. If you have any ideas or tools in mind that can help us achieve this, feel free to contribute to the discussion.
Let's work together to improve our workflow and make LWKD even more efficient. Your input is highly appreciated!
The text was updated successfully, but these errors were encountered: