logseq/pages/TSE-2023-11-0555_Proof_hi.md

type:: REVIEWS tags:: github PullRequests year:: 2023 venue:: TSE full-title:: Improving Issue-PR Link Prediction via Knowledge-aware Heterogeneous Graph date-submitted:: 04-01-2024 date-start:: 15-11-2023 - 22:27 status:: DONE deadline-submission:: 13-12-2023 file::

- [[Highlights]]
	- #+BEGIN_IMPORTANT
	  ((659594b4-ee0f-4c4a-b63c-e41c58680f9c))
	  ((659594d1-edcb-40ea-850b-52db01f83473))
	  ((65959898-39d0-49da-a753-3b02620ea660))
	  ((65968613-a566-4d24-9b99-3af0f6372bc9))
	  ((6596ce97-647e-436f-a177-0e76b1ea9383))
	  #+END_IMPORTANT
	- ((6595730f-c19a-4453-a41f-077491bba291))
		- ((6595733c-36f4-444d-8fb7-f911dcc917fc))
		- This is too far.
	- ((65959707-79f7-4b35-bdc1-3fd8326416e3))
		- It should be 29248, isn't it?
	- ((65959792-0254-4723-9952-99110bf3b1ac))
		- Where is it?
	- ((659599fb-8ff2-46e9-978b-829bb68d6dac))
		- **I-I**: Issue - Issue relationship, i.e., similar issues
			- ((65959a51-4654-4cee-9fff-553b7978d13f))
		- **I-R-I**: Issues of the same repository that provide different information about the repository at hand.
		- **I-R-R-I**: ((65968326-4ab4-4340-b47d-51d56f879b69))
		- **I-U-I**: ((6596838d-c419-42fd-9168-1566f8d6cb3b))
		- **I-U-R-U-I**: ((65968440-924f-4c4d-9e39-8eff172722e2))
			- ((65968494-d3ee-415c-b69a-de54c3d9bc49))
			- ((659684a4-99e7-40f1-ad59-650940805334))
		- **I-R-U-R-I:** ((65968543-b6b5-4565-9b40-defdefb10dfa))
	- ((659685b7-1ce2-4553-9d4c-753e290cd8c0))
		- ((65968700-6f86-4540-bb7d-55c401547f4d))
			- What do you mean? You need to explain such a dimension decision. At least give examples of considered features.
		- ((65968a31-ad3a-436f-b8d0-c18f2e28fee3))
			- even the user encoding mechanism is not clear.
	- ((65968a5b-eaa6-4479-b476-7112e4224831))
		- As a general comment, since authors stress the task-specificity of the constructed graphs, it is necessary to explain how the task specificity is considered in the process.
		- In the title instead, the authors refer knowledge-aware graphs!
	- ((65968b48-6612-4b6b-9278-59d1c314675d))
		- There are many works that propose ways to calculate the similarity of github repositories. Authors should mention this at least in the related work section.
	- ((65968cc7-956f-485d-93d3-660ab330b1cd))
		- This is related to some of my previous comments. It is needed to motivate and explain such dimensions.
	- ((65968d86-3e1d-48d5-8c5b-a09607a81ab8))
		- A concrete example can help.
	- ((65968edb-6147-4c5f-96ec-ffb4d0825cd5))
	- ((65968f61-185f-4a41-a3ac-f0e1757ef85a))
		- What do you mean?
	- ((65968f85-77f2-47e4-9383-329524922a9e))
		- analysis **of** 12 ?
	- ((65968ff9-fcb8-4a76-b187-2a47a5dc668a))
		- The term metapath is used interchangeably to refer both the catalog presented in 2.3 and to their instances that can be detected when analyzing real projects. This makes the presentation sometimes confusing. For instance, the aggregation process presented in section 3.2 refers to metapath instances, isn't it?
	- ((6596ccf0-a01e-4520-a27f-f3fbae40da0e))
		- Again the task specificity of graphs is mentioned here
	- ((6596cd40-4729-46b3-bdb7-6cb147aac7ab))
		- What's the goal of this research question?
	- ((6596d3f2-03ed-4fdf-b523-c005696fd88a))
		- Procedure?
	- ((6596d7e3-b4d9-4358-bb82-5bd8ada7bc6c))
		- Does this represent a bias?
	-
- [[Comments]]
	- SUMMARY: The paper presents AIPL, an automated approach to predict links between pull requests and issues of GitHub repositories. The approach relies on a catalogue of metapaths, i.e. different patterns of relationships linking different GitHub assets, i.e., issues, repositories, pull requests, and users. By mining Github repositories, the proposed approach can encode such assets with the discovered relationships and train a prediction component, which can recommend possibly missing relationships among existing Github issues and pull requests. The approach has been evaluated using the facebook/react and vuejs/vue repositories to answer three research questions. According to the performed evaluation, AIPL outperforms the existing baselines.
	  
	  COMMENTS: The paper is well-written and structured, presenting a promising approach for predicting links between pull requests and issues in GitHub repositories. The evaluation is thorough, and the proposed AIPL outperforms existing baselines. However, some minor concerns need attention before acceptance:
		- The decision to use a 50-dimensional vector should be clarified. Examples of considered features or an explanation for this dimension choice would enhance understanding.
		- The mechanism for user encoding using randomly selected integers needs further clarification for better understanding.
		- The paper should explicitly explain how task specificity is considered in constructing task-specific heterogeneous graphs, especially considering the mention of knowledge-aware graphs in the title.
		- The motivation and explanation for different embedding dimensions, such as the example given for users having a dimension of 10 while others have 50, should be provided.
		- A concrete example illustrating how all nodes' projected embeddings share the same dimension after a specific operation, as mentioned in [35], would enhance clarity.
		- The phrase "to integrate the information under each metapath" needs clarification for a better understanding of the process.
		- The paper should address the confusion arising from using the term "metapath" interchangeably for both the catalogue and their instances, especially in Section 3.2.
		- The paper should discuss whether initializing vectors with random values for empty content represents a potential bias and its implications.
- [[REVIEWS/Notes]]