Since Github has a Search API limit, a chunk_size parameter was added where the user can set the number of days in 1 chunk which could be the best fit for getting nearly 1000 results. For large repositories like vscode and kubernetes this size drops to 20-25 days while for smaller repositories this raises till 200+. Currently, it is very hard for the user to correctly predict the optimal chunk_size which would not miss any issue/pull request.
GRAS should have its own chunk_size predictor which should be chosen based on the number of average closed or open issues present within x days.
Later on, the functionality should be extended to chunk_size's of different lengths which exactly fits 1000 issues / pr's in it.
Since Github has a Search API limit, a
chunk_sizeparameter was added where the user can set the number of days in 1 chunk which could be the best fit for getting nearly 1000 results. For large repositories likevscodeandkubernetesthis size drops to 20-25 days while for smaller repositories this raises till 200+. Currently, it is very hard for the user to correctly predict the optimalchunk_sizewhich would not miss any issue/pull request.GRAS should have its own
chunk_sizepredictor which should be chosen based on the number of average closed or open issues present withinxdays.Later on, the functionality should be extended to
chunk_size'sof different lengths which exactly fits 1000 issues / pr's in it.