[DISCUSSION] Check open PRs and tell if someone has already suggested an icon or linked a component

[x9136]

About this discussion

The more open PRs there are, the more time it will take to check which icons have already been suggested.

Theoretically you can check both by svg name and by component names at once. After a person has created a PRs, he can be told that the icon is already there or the component has already been linked. Give a link to the PRs where this happened.

But the actual problem is that there is no common table where contributors can say that they have taken a request into work. This is also superimposed on the fact that nobody updates the table of requests — now at least half of the rows there are irrelevant. The requests themselves consist of clipped component names. Such names are useless for apps that can be installed only on specific phone brands and you always have to search full component names for each request.

Therefore, if we talk about a normal process, then we have a public table, which receives whole components from those who want new icons. Contributors in such a table could label with a date the requests they are working on. Other contributors would see the overall situation, so that they don't waste their time or the reviewer's time on the same requests.

Once a contributor has created a PR, you could mark the requests in the table as ready to review. And after the PR is accepted, you can remove completed requests from the table. But even if it takes a lot of effort to do this automation, leaving the manual ability to mark rows as "in work" and "done" via the comment feature would help to save time. I assume that it is possible to solve this problem in other ways.

[KTibow]

GitHub has Projects, you would need an admin to set them up though

[x9136]

GitHub has Projects, you would need an admin to set them up though

Is there an easy way to write responses from the requests form to GitHub Projects? My guess is that there isn't.

But I know that it's easy to make the current requests table to fit a new workflow.

[KTibow]

Given each request is a separate issue, you can comment on them that way If each one is a separate issue you could also just use labels or milestones to track them

[x9136]

Given each request is a separate issue, you can comment on them that way If each one is a separate issue you could also just use labels or milestones to track them

A lot of users write requests in batches. It looks like this:

nz.co.kiwibank.mobile
nz.co.bnz.droidbanking
com.hjiangsu.thunder
app.symfonik.music.player
nz.co.telecom.smartphone.android
nz.co.partpay.mobileapp
com.github.olga_yakovleva.rhvoice.android

So, if I understand you correctly, in this case it will be necessary to compare requests between each other and see who has the same components to keep information up to date. Or we will have to put the task of sending the request one by one on the users. Or we'll have to force contributors to make requests based on a particular user's list, rather than in the desired order. Either way you lose flexibility for either users or contributors.

In addition, you can tell from the table which requests are the most popular. This allows you to set priorities in a more meaningful way. I'm not sure if it will be possible to see the popularity of requests through Projects without the need for additional actions on the part of users.

[KTibow]

Users can :+1: issues pretty easily - but yeah it would still be hard to open each issue separately

[x9136]

Users can 👍 issues pretty easily

Yes, they can, but let's put ourselves in the user's shoes. I want to request 10 new icons. I have 2 options.

1. I send the components through the form.
2. I check 10 times through search to see if someone has already asked for the same thing. If there is a request I put :+1:, and if not I go create a new one.

[KTibow]

Fair, but even if you used a sheet wouldn't someone in the team still have to see if each icon was requested already or not

[x9136]

if you used a sheet wouldn't someone in the team still have to see if each icon was requested already or not

Are you saying that seeing it would be more convenient here than opening a sheet? If I understand you correctly, it would be great if GitHub supported tables.

The point is, I'm trying to solve the problem without development and tables look like a good option. With development the problem would have a very different solution, I wrote about one option in a past issue.

[KTibow]

Bit confused right now - are you proposing a publicly editable table, a privately editable table, or something else? (Also Github Projects has a table view but :shrug:)

[x9136]

are you proposing a publicly editable table, a privately editable table, or something else?

Right now I'm proposing to do something like that. "RAW RQ" is actually a requests table, in which a bunch of components are separated using formulas so that there is one component per row. "Popular RQ" is a pivot table that collects components by popularity.

Seems like you could do the same thing with Lawnicons table. And in a pivot table you can allow comments, so that contributors can mark which icons are in progress and which ones should be removed.

[KTibow]

https://docs.google.com/spreadsheets/d/10_o0DjhAGfP8ToDDNQ8M7eCZKtbzXLhIvxuF1XZEql0/edit?usp=sharing Let me know if Sheets didn't let you copy the Apps Script so I need to send it to you Also are you on Discord? I couldn't find you in the Lawnchair Discord, it would be nice to be able to quickly contact you there.

[x9136]

For those who periodically work on icons, there is a reminder in the requests table to check for open PRs.

Also, duplicates don't happen very often and are caught by the contributors. If a duplicate is overlooked and merged with a repository, it doesn't break Lawnicons and is easy to fix in another PR.

So there will be little benefit from automatic match checking to make it worth developing.