  We aim to explore how developers document their refactoring activities during
the software life cycle. We call such activity Self-Affirmed Refactoring (SAR),
which indicates developers' documentation of their refactoring activities. SAR
is crucial in understanding various aspects of refactoring, including the
motivation, procedure, and consequences of the performed code change. After
that, we propose an approach to identify whether a commit describes
developer-related refactoring events to classify them according to the
refactoring common quality improvement categories. To complement this goal, we
aim to reveal insights into how reviewers decide to accept or reject a
submitted refactoring request and what makes such a review challenging.Our SAR
taxonomy and model can work with refactoring detectors to report any early
inconsistency between refactoring types and their documentation. They can serve
as a solid background for various empirical investigations. Our survey with
code reviewers has revealed several difficulties related to understanding the
refactoring intent and implications on the functional and non-functional
aspects of the software. In light of our findings from the industrial case
study, we recommended a procedure to properly document refactoring activities,
as part of our survey feedback.
