Looking at the PDF you posted on the other thread, it appears that users who did not fill out the migration google-sheet have their comments migrated with no author-attribution of any kind (not name, not username, or even “Anonymous LLVM Contributor #123”. Is that correct?
That’s correct. All such contributions will be attributed to
“llvmbot”. There is no other way we can enter “anonymous” data to
github. However, we do provide the backlink to the original bz issue.
We have to anonymize the data in order to comply with some regulations
and there is no way to save the attribution without the explicit
If we can attribute it to an anonymous entity, e.g. by putting “Anonymous LLVM Contributor 123 wrote:” at the top of a comment by llvmbot, at least readers can understand whether two comments on a bug are from the same person or from different people, for example. Can we at least do something like that?
Thus, it seems pretty important that at least all of the active contributors have filled out the sheet before the migration – have they?
There are more than 1k users with commit access to LLVM repo.
Approximately half of them filled the survey. However, there is no
way we can force the contributor to give consent.
Certainly I wasn’t asking to force anyone. Rather, I wish to ensure that the people aren’t going to be surprised and unhappy when they realize they were omitted! I’d like to make sure folks are given every opportunity to fix that, before it’s too late.
I expect nearly everyone who is actively interacting with LLVM bugzilla wants to be included in the migration mapping. Certainly there’s going to be a rare person who actively doesn’t want it, and a long tail of people who are no longer active in the community, or not easily contacted, who will be excluded because they’re unresponsive. But, if there are many people who are currently active in the community (e.g. active on bugzilla or making commits), and yet have not filled out the survey, I think that indicates that we have a problem with outreach.
And, if such a problem exists, I think we ought to address that problem before migration.
everyone who cared about “saving” the contributions would’ve filled the form by now.
I very much doubt it’s true that everyone who cares will have filled it out already. I mean, just speaking for myself…I think I filled out the form? But maybe I only intended to, but forgot to get around to it? Who knows. Assuming I actually did, I’m certain there are more people in the same situation who actually did not.
And on a more general note –
It worries me how little information has been communicated with the community overall for this project, especially now that the migration is supposed to happen imminently! I completely understand how painful it can be to do a migration like this, and how it can feel annoying to have people bugging you about things, yet not actively helping to complete the migration. But…we are going to be stuck with this conversion for a long time, so it is important to validate that people are going to be overall happy with it, right?
Some other questions that pop into my mind:
Has a full test migration been done now? Or is it impossible to do a full test migration?
What happens if the migration fails in the middle due to an unforeseen error?
What sorts of verifications of correctness have been done on the migration output?
What problematic cases are “known issues” which have been deemed unimportant and therefore ignored?
How are comments migrated? (e.g. it would appear that some effort was put into ensuring that english prose gets migrated as variable-width text, and code sections get migrated as fixed-width text?)
How is all the other data migrated? Is all of it migrated? Or are certain fields deemed useless, so we don’t migrate them?
Can we let additional people have access to a test migration, to verify that it seems reasonable? Even if it can’t be made public, can the migration can be done to a private repository which can be opened to other llvm community members? (A couple PDFs is certainly better than nothing, but…) What’s preventing the ability to do that?
Is there code that implements this migration that folks can look at and/or suggest changes to?
Or, really, more fundamentally – where’s the document describing the plan? I think that’s the root of the issue – there should be a plan written up, not just one-off answers to those questions that popped up in my mind I listed above, but a document fully describing the final plan for this migration, and why each choice made there is thought to be the best option (or, at least, best practical option, if not actually the best).
I note that people posted suggestions on the previous thread which were dismissed as outdated and unhelpful – but that’s because nobody else has been told any of the information about what tradeoffs have already been considered and dismissed, and what the actual problems are/were. Having a written plan would also help ensure people aren’t going to give unhelpful redundant suggestions…