refactor: improve get pop issues

[sdiazlor]

Pull Request Template

Closes #5116

CONSIDERATIONS:

• I fixed the planned issues, BUT to order them in descending order, I had to filter by v2. and the open ones (there were old milestones, and if the closed ones are shown, only those will be shown). FOR DISTILABEL UPDATE, the v2 filter should be removed.
  I removed an API call as I found a key to determine if a member of the org/repo opened the issue (pre-commit should not be additionally added as previously because it only creates PRs, not issues). Locally, with a token with the permissions defined, it correctly removed the members.
• I realized that the API call to list the issues also retrieves the pull requests, so I added an if statement to filter them.
• I removed unneeded keys.

Type of change

• Refactor (change restructuring the codebase without changing functionality)
• Improvement (change adding some improvement to an existing functionality)
• Documentation update

How Has This Been Tested

Checklist

• I made corresponding changes to the documentation
• I confirm My changes generate no new warnings

[nataliaElv]

Thanks @sdiazlor ! Everything looks good. I just don't understand very well why planned issues need to be filtered by "v2". I think this might make the code difficult to maintain in the future, although it might work for now.

If we cannot find a good solution to this, maybe we can eliminate this section. Here is my thinking:

1. milestones can be easily checked in github, so this section is redundant. -> possible solution, add somewhere a link to our github milestones.
2. I'm not sure how useful it is for the community to see all the internal tasks that we have planned for each milestone. It's probably more interesting to see if the popular issues / community issues have been selected for a specific release -> possible solution, add to these two tables a "Milestone"/"Expected version" column.

What do you think @sdiazlor @davidberenstein1957 ?

[davidberenstein1957]

@nataliaElv I think we can keep it assuming the next sentence is correct. We filter on startswith v2 to avoid potential other issues showing up so this wouldn't require any updates until v3, correct @sdiazlor? I agree we can find issues and milestones on GH but not everyone is as familiar with using open-source GH so it might be a good indirect funnel to guide people there.

[davidberenstein1957]

Given the discussion I would personally accept.

[sdiazlor]

@nataliaElv @davidberenstein1957 Yes, "v2" doesn't need to be updated until "v3". The reason to filter it is that, in descending order, the first milestones are shown, so it would show the 1.x first (some are still open).

[nataliaElv]

I'm just saying that we should find a solution for future versions for these reasons:

1. Sometimes we forget to add v in front of milestone names 😅 We can try to be careful with that, but human error happens.
2. By the time we get to Argilla 3.x, will we even remember that we added a starts with v2 filter in some hidden line of the docs code?
3. Do users who check our documentation really want to see all the small technical tasks that we assign to those milestones? I don't think so. Specially those that @davidberenstein1957 mentions not being familiar with GH.
   Perhaps the v1 issues that are open should be either closed or have the milestone removed 😅 I'll check those to clean them up anyway.

[nataliaElv]

Anyway, we can merge this change and find a solution later on 🙂

[sdiazlor]

@nataliaElv Then, maybe you're referring more to the roadmap? But then they can go to that page, that's why I believe they are different things. Or, in any case, instead of the planned issues in detail, add the roadmap issues ¿?