Update _contributing-code.md #804
Conversation
adding the /swift contributing guide and removing the rest of the duplicate text from it
parispittman
requested review from
0xTim,
alexandersandberg,
daveverwer,
dempseyatgithub,
kaishin,
shahmishal,
timsneath and
federicobucchi
as code owners
|
|
||
| In addition, don't commit changes authored by others unless they have submitted the change to the project or you have been authorized to submit on their behalf---for example, you work together and your company authorized you to contribute the changes. The author should first either submit the change through a pull request to the relevant project, email the development list, or add a bug tracker item. If someone sends you a change privately, encourage them to submit it to the appropriate list first. | ||
|
|
||
| ### Code Templates |
There was a problem hiding this comment.
Are we going to remove this section for good? If so, I would really appreciate some rationale. There are around 25 subprojects across swiftlang & apple that this applies to.
There was a problem hiding this comment.
We aren't removing this for good. This entire section went into the /swift/CONTRIBUTING.md file.
There was a problem hiding this comment.
https://github.com/swiftlang/swift/blob/main/CONTRIBUTING.md
We've removed the text from the main code since it's pertinent to contributing to the core Swift repo and saves a lot of scrolls for the first time contributor.
There was a problem hiding this comment.
I strongly believe that the sections I pointed out are best published in a central location where information is understood to relate to the project as a whole. Speaking of the code headers, my impression is that they are supposed to be followed by all subprojects.
There was a problem hiding this comment.
One of the pieces of the unified information architecture project is working through where the various pieces of contributor content should be located. This is a good example of that. @AnthonyLatsis would you be able to join in these conversations? The intent is to have a small group propose the information architecture for contributor info to the contributor experience workgroup.
I don’t believe the current Contributor page or the version with this PR are the final iteration of the Contributor page. I agree that, as much as possible, things that apply to all or most projects should live in a single central place. But, I also don’t think that they all need to be on the Contributor landing page on Swift.org.
I see the page as it is (or with this PR) as something that will likely change significantly once we go through the information architecture process. I personally am fine either way, but I would like to minimize the amount of thrash of moving things around before we have discussions about where they should go.
There was a problem hiding this comment.
Totally agree about this not being the final iteration. This is a clean up effort and the intent would be to have this page re-written with the efforts that James is discussing.
There was a problem hiding this comment.
While we are in the process of discussing where to put contributor information in general, I thought /swift could be a good temp home for this information until a) we clean this guide up and rewrite it and b) we have a repo set up like GitHub.com/swiftlang/contributors to house all things contributors.
There was a problem hiding this comment.
These sections could certainly be modernized and/or moved to an agreed upon central location later. I suggest keeping them in place until we actually get to that:
- We are less likely to forget about them if they stay in the original location, in plain sight.
- A direct move is a simpler and more transparent change, more so if we decide to keep the information on the website.
- There are links to at least one of these sections in several repositories that would need tending to more than once otherwise.
would you be able to join in these conversations?
@dempseyatgithub Likely not as actively as I want to, but if lower than average time commitment is acceptable, then yes please!
|
|
||
| The divider lines should be exactly 80 characters wide to aid in adherence to the code style guidelines. The bottom section contains an optional description intended for generated documentation (these lines begin with `///` rather than `//`). If there is no description, this area can be skipped. | ||
|
|
||
| ### Release Branch Pull Requests |
There was a problem hiding this comment.
This is pertinent to all projects that have compiler-aligned release branches.
|
|
||
| For minor violations of these guidelines, the community normally favors reminding the contributor of this policy over reverting. Minor corrections and omissions can be handled by sending a reply to the commits mailing list. | ||
|
|
||
| ### Attribution of Changes |
There was a problem hiding this comment.
I don’t see how these rules around attribution of changes are not applicable to all projects either.
|
Now that we are taking this file apart I would like to suggest a one sentence per line format. |
I think the website workgroup would want to discuss this and either adopt it site-wide or not. Definitely worth filing an issue for the website repository. |
|
@dempseyatgithub Opened #819. Would you be able to put this on their meeting agenda? I still think it prudent to take advantage of a clean slate and adopt it in this file in the meantime. Semantic line breaks are clearly more apt than the casual line per paragraph format, and from what I gather, this repository does not follow a specific line break convention anyway. |
shahmishal
added
the
info-architecture
adding the /swift contributing guide and removing the rest of the duplicate text from it