After legal consult, The LLVM Foundation board is ok with the change to the license on these files.

I think these changes are pretty straight forward. If anyone wants to give the thumbs up, please do so. You don't need to be owners of the related websites/docs.

Fix typos.

Looks good!

This can be another patch, but I would like to add a point of contact to all sync-ups for CoC purposes. This should also be included in the calendar notes. I'm happy to create the patch though.

Fix a couple typos.

In D121078#3402469, @aaron.ballman wrote:

In D121078#3400810, @SimplyDanny wrote:

@tonic, can you please have another look?

If @tonic has any additional feedback, we can handle it post-commit at this point. I've gone ahead and committed this on your behalf in a749e3295df4aee18a0ad723875a6501f30ac744.

(Note, I can't close this review because of the "changes requested" state for tonic.)

@hubert.reinterpretcast - Can you accept if you believe I have made all your requested changes?

Updating based upon reviewer feedback.

So sorry, I think my ResponseGuide changes got reverted. I am going through these again to make sure they actually got completed.

In D77912#3465723, @compnerd wrote:

In D77912#3465615, @tonic wrote:

In D77912#3465553, @MaskRay wrote:

In D77912#3465400, @tonic wrote:

Unfortunately, this patch violates copyright of the The PowerPC Compiler Writer's Guide. Please revert this patch, remove the copyrighted code, and you can submit a new patch for the other changes. For future patches that use guides with copyright, please consult with the LLVM Foundation board before committing. Thank you!

If this request is related to "// Translated from Figure 3-40 of The PowerPC Compiler Writer's Guide" in the code, then I think it should apply to the very first commit
fd089990f76ec6392dbd0138ab874d90c632d2a4 (2009) by @ddunbar .

This patch merely copied this old comment. I don't think I am the appropriate one to take any action here.

Please also read the nature of the patch :)

My apologies for missing that. I will be creating a patch to remove this then and other references.

I believe that the comment may be referring to the algorithm rather than the implementation itself as the book provides assembly listings for PPC.

In D77912#3465553, @MaskRay wrote:

In D77912#3465400, @tonic wrote:

Unfortunately, this patch violates copyright of the The PowerPC Compiler Writer's Guide. Please revert this patch, remove the copyrighted code, and you can submit a new patch for the other changes. For future patches that use guides with copyright, please consult with the LLVM Foundation board before committing. Thank you!

If this request is related to "// Translated from Figure 3-40 of The PowerPC Compiler Writer's Guide" in the code, then I think it should apply to the very first commit
fd089990f76ec6392dbd0138ab874d90c632d2a4 (2009) by @ddunbar .

This patch merely copied this old comment. I don't think I am the appropriate one to take any action here.

Please also read the nature of the patch :)

Unfortunately, this patch violates copyright of the The PowerPC Compiler Writer's Guide. Please revert this patch, remove the copyrighted code, and you can submit a new patch for the other changes. For future patches that use guides with copyright, please consult with the LLVM Foundation board before committing. Thank you!

I'd like to get this finalized this week, so if past reviewers are happy, please accept.

Addressing the reviewer requested changed.

I have addressed all the comments or responded why I did not make the change. I will be updating the patch next.

This is breaking the docs build with the following warning: "MisExpect.rst:document isn't included in any toctree." By default, docs warnings are treated as errors. Can you fix this?

In D121614#3394221, @nlopes wrote:

In D121614#3394190, @asl wrote:

@nlopes I think we need to better frame the requirement then, ask for CVs (this is always done though) and maybe even organize some kind of interviews? Strongly favouring ones with prior contributions is a good thing IMO

I agree, I interview students these days.

We should incentivize folks with prior contributions, totally (though that's extremely rare). At least a bug fix so we know they can code. Usually fixing some InstCombine/InstSImplify bug is within reach of newbies.

Another idea, would it be ok to link directly to either Discord or Discourse usernames for the mentors? That way it is easer to find or tag people.

Adding changes to the Open projects page to remove old GSOC data and link to the landing page. Add a link to a GSOC template

In D121078#3367950, @aaron.ballman wrote:

In D121078#3367289, @tonic wrote:

In D121078#3366825, @aaron.ballman wrote:

In D121078#3366025, @tonic wrote:

In D121078#3365542, @SimplyDanny wrote:

In D121078#3363856, @aaron.ballman wrote:

I think we need to retain *some* references to the existing mailing list archives. The migration to Discourse worked fairly well, but there were still data migration issues. For example:

Do you have some prominent places in mind where the archives should be mentioned? For me as someone who just started to get a bit more involved into LLVM, the archives are not very helpful. There is no way to search for threads as far as I know. That means it is very hard to find anything specific. That is why I actually came up with this change in the first place: Getting rid of references to the "old' mailing lists which are just not helpful for beginners.

Oh, I think these changes are *fantastic*, so I'm happy we're updating the stale references to point to the more modern place to go. Thank you for that!

There are ways to search the archives (as Tanya mentioned, you can use a google site search over them), but you have to know they exist to know to do that, which is why I'd like to retain some mention of them until the migration moves over *all* of the historical data. It's not super handy for most folks, so I don't think we need a *prominent* place for this. But it is handy for those of us who have to do a fair amount of historical digging around to see how we came to the conclusions we came to (not a common activity, but it is not uncommon for folks on standards committees to be asked "why does your implementation do X?" and need to go looking).

AFAIK, we have never had link to the archives and instructed people to go search them aside from the link on the Mailman list info page.

This patch removes the links to where the archives can be found. I have instructed people to go search those archives on multiple occasions as part of ISO standards work.

In addition, knowing they exist is also something that was not super obvious to many people who have not used Mailman. I want to avoid adding references to archives in all of these places because it defeats all the work to go and update the locations to have to go back and do it again.

I know you want to avoid all mentions of mailman. I want to avoid losing information that is still relevant for the foreseeable future. The places I want to see updated already list mailman for the commits lists, so I don't agree that my request adds a material burden for the future.

It is also confusing to newcomers to the project.

This is why I suggested using a footnote to make it much more clear that this is a secondary option. Not everyone in the project is a newcomer, but we still need to support them. I'm not at all tied to this solution of using footnotes if you have a suggestion for a less intrusive approach to accomplish the same goal.

I think the least distracting thing we could do would be to put a superscript footnote after any link to a particular discourse forum which goes to an anchor at the bottom of the page to a footnote saying something like what I recommended below. This should keep the focus for most people on going to Discourse, it shouldn't be overly distracting or confusing to people new to the docs, but it still retains useful information that some folks need.

You do not need to worry about this.

In your opinion, that may be true; in mine, this is still a concern.

I don't think its fair to ask this person to be the one to add links to the archives and handle the situation. They are being put in the middle of an argument.

The author changed a bunch of links in good ways but also did so in a way that loses information in a few places that I don't wish to see lost. You disagree. That's fine and is very normal part of patch review. It's not an argument for reviewers to find consensus among themselves when there are disagreements.

Your change is updating the locations people are to ask for help.

The change is also touching Mailing List & Forums content, which are not specifically about asking for help (they can also be for reading instead of writing).

Again, we have never told people to search the archives. There isn't even a "Search" box on the archives.

I ask folks to search the archives. I think Discourse should cover the vast majority of those situations without issue. However, not knowing that we have more complete archives elsewhere does not help those folks for whom the questions are not "it'd be nice to know" but are "I need to know." These are the people I want to continue to support.

I've added comments to the few places I'd like to see a change, which hopefully makes my request more clear. I am carefully trying to avoid adding this extra information to the places we're documenting people to go for discussion; I think those should continue to only point to Discourse. But the places where we have quick links for more useful information are where I think we should retain some unobtrusive mention of the complete archives.

In D121078#3366825, @aaron.ballman wrote:

In D121078#3366025, @tonic wrote:

In D121078#3365542, @SimplyDanny wrote:

In D121078#3363856, @aaron.ballman wrote:

I think we need to retain *some* references to the existing mailing list archives. The migration to Discourse worked fairly well, but there were still data migration issues. For example:

Do you have some prominent places in mind where the archives should be mentioned? For me as someone who just started to get a bit more involved into LLVM, the archives are not very helpful. There is no way to search for threads as far as I know. That means it is very hard to find anything specific. That is why I actually came up with this change in the first place: Getting rid of references to the "old' mailing lists which are just not helpful for beginners.

Oh, I think these changes are *fantastic*, so I'm happy we're updating the stale references to point to the more modern place to go. Thank you for that!

There are ways to search the archives (as Tanya mentioned, you can use a google site search over them), but you have to know they exist to know to do that, which is why I'd like to retain some mention of them until the migration moves over *all* of the historical data. It's not super handy for most folks, so I don't think we need a *prominent* place for this. But it is handy for those of us who have to do a fair amount of historical digging around to see how we came to the conclusions we came to (not a common activity, but it is not uncommon for folks on standards committees to be asked "why does your implementation do X?" and need to go looking).

In D121078#3365542, @SimplyDanny wrote:

In D121078#3363856, @aaron.ballman wrote:

I think we need to retain *some* references to the existing mailing list archives. The migration to Discourse worked fairly well, but there were still data migration issues. For example:

Do you have some prominent places in mind where the archives should be mentioned? For me as someone who just started to get a bit more involved into LLVM, the archives are not very helpful. There is no way to search for threads as far as I know. That means it is very hard to find anything specific. That is why I actually came up with this change in the first place: Getting rid of references to the "old' mailing lists which are just not helpful for beginners.

Thank you so much for doing this! I have added some comments inline that I would like changed.

Unfortunately our legal counsel has advised that this patch should not be included into LLVM because the exact patent burden is not disclosed. Therefore, we can not accept this patch into LLVM. I am very sorry to have to report this disappointing news.

Thank you!

In D111723#3066546, @kuhnel wrote:

Thx everyone for the reviews, I updated the proposal accordingly.

@tonic
Let me know if you want to see (parts of) this change moved to DeveloperPolicy.rst.
My rationale was: Keep info we only need a handful of times per year out of DeveloperPolicy.

This is just general comment as I want to read this and think a bit on it, but I think that any criteria about adding a repo should only be in the developer policy. The rest about what to do after, can remain in a separate document.