type:: [[REVIEWS]]
tags:: [[Open Source Software]] 
year:: 2023
venue:: [[JSME]]
full-title:: The vital role of Community of Open [[Source]] Software Development
date-start:: 
external-links:: ![JSME-23-0044_Proof_hi_1681241817412_0.pdf](../assets/JSME-23-0044_Proof_hi_1681241817412_0.pdf)
status:: [[DONE]]

	- [[Highlights]]
		- ((64415005-3c95-4351-ad8b-60da82a403f5))
			- Any baseline has been used?
		- ((644240e6-721e-4ca0-a2e2-7a1d211e3c5e))
			- This part needs to be improved to make it easy to read.
		- ((64424188-2173-4125-ba54-6eb573120d73))
			- This subsection is misplaced. It cannot be given in the section presenting the related work. Moreover, to make stronger the need for the proposed quality model, it is necessary to present a comparative table showing all the peculiar characteristics of the summarized quality models so that the authors can explicitely distil the quality characteristics that are not supported by existing quality models.
		- ((64425595-2c1b-4ada-a52f-8b8ffc5b2afc))
			- As usual this can be subjective.
		- ((644255b2-3e8a-4f11-9ef4-738a2d64f66b))
			- Let's see if there is evidence about this later in the paper.
		- ((64425750-23d8-4075-9841-e3b2dd802ca9))
			- The definition can be ok, but the implementation I guess is for GitHub, isn't it?
- #+BEGIN_CAUTION ((64425d67-58a3-4a0a-9d07-a433eead8555)) #+END_CAUTION
	- ((64425db6-3c4c-4d73-816c-4050083af29f))
		- This is a strong assumption
	- ((64425e20-774f-4c50-a54c-4bc7ebce2640))
		- I think this is not good because projects are very different. Projects can have different historys, started in very different years, so the communuties can be very different!
		- A manual validation of the obtained results should be given
			- Moreover, who are the main stakeholders of the proposed tool / approach?
			- Developers/contributors might be interested in be engaged in more active communities. From a user point of view, final users might be interested in aspects / discussions that are less technical and more related to how the community is willing to help final users.
	- [[Comments]]
		- **Overview**: This paper proposes an approach to evaluate the quality of open source project communities. The approach is based on a quality model that defines a set of quality characteristics, which are organized and aggregated in a hierarchical structure. The quality model is operationalized by 24 metrics that can be automatically measured from the project data. The approach has been applied to 7 open source projects, randomly selected from GitHub, to demonstrate its feasibility and usefulness.
		- **Comments:** The paper addresses an interesting and relevant problem. However, there are several concerns that need to be addressed before it can be accepted:
			- The related work section should be improved by adding a table that shows all the considered quality models and compares them based on their distinguishing characteristics. This will make it clear why it is necessary to add a quality model specifically designed to assess the quality of OSS communities.
			- Additionally, the novelty of the proposed approach should be compared with existing technologies like the ones developed in the context of the OSSMETER project. For instance, the authors should clarify if the quality model proposed in Fig. 2 can be or not a specific model defined with the tools developed in the context of the OSSMETER.
			- Motivations supporting the selection of the metrics given in Table 1 should be provided. It is necessary to explain why these metrics were selected and how they are relevant to assess the quality of OSS communities.
			- Section 4, which is intended to be about the implementation of the proposed framework and the performed validation, needs improvement. A dedicated section should be added to give details about the approach that has been developed and how to use it. Concerning the validation, the selection of the 7 OSS projects needs to be addressed. The authors randomly selected them without any specific constraints, which could be a relevant bias, especially when the assessment output is used to compare them. The considered projects are of different application domains, have different histories, and were created in different years. Therefore, it is not clear if ranking them and comparing them in the same list makes sense. Additionally, the use of the approach in general should consider that developers and contributors might be interested in engaging in different communities for different goals. For instance, final users might be interested in aspects/discussions that are less technical and more related to how the community is willing to help them.
			- In conclusion, the paper needs major revisions before it can be accepted. The authors should address the concerns mentioned above and provide more explanations, justifications, and details to improve the overall quality and clarity of the paper.