Is it OK to update code on repository after publication?
Journals consider that is good practice to release script and codes to repeat the published results, and many of us I think agree with this practice. Code are typically deposited in software version control repositories (e.g., GitHub or BitBucket).
I wonder if updating the codes during reviewing process or after publications (which in my opinion is quite important, in general) remains a good practice.
Maybe the obvious answer is yes, but for example it is certainly not good to modify the data deposited for a published article (or modify its pre-print in a pre-print server).
publications code
New contributor
add a comment |
Journals consider that is good practice to release script and codes to repeat the published results, and many of us I think agree with this practice. Code are typically deposited in software version control repositories (e.g., GitHub or BitBucket).
I wonder if updating the codes during reviewing process or after publications (which in my opinion is quite important, in general) remains a good practice.
Maybe the obvious answer is yes, but for example it is certainly not good to modify the data deposited for a published article (or modify its pre-print in a pre-print server).
publications code
New contributor
add a comment |
Journals consider that is good practice to release script and codes to repeat the published results, and many of us I think agree with this practice. Code are typically deposited in software version control repositories (e.g., GitHub or BitBucket).
I wonder if updating the codes during reviewing process or after publications (which in my opinion is quite important, in general) remains a good practice.
Maybe the obvious answer is yes, but for example it is certainly not good to modify the data deposited for a published article (or modify its pre-print in a pre-print server).
publications code
New contributor
Journals consider that is good practice to release script and codes to repeat the published results, and many of us I think agree with this practice. Code are typically deposited in software version control repositories (e.g., GitHub or BitBucket).
I wonder if updating the codes during reviewing process or after publications (which in my opinion is quite important, in general) remains a good practice.
Maybe the obvious answer is yes, but for example it is certainly not good to modify the data deposited for a published article (or modify its pre-print in a pre-print server).
publications code
publications code
New contributor
New contributor
New contributor
asked 6 hours ago
altrowarealtroware
2112
2112
New contributor
New contributor
add a comment |
add a comment |
3 Answers
3
active
oldest
votes
Absolutely yes! There is no reason to stop a project from evolving just because you've published about it.
What would be good to do, however, is to identify the version current at the time of publication with a release version or other similar sort of tag. You can point to the specific tag in the publication and also have the repository tag point to the publication through its associated comment text.
This will allow a reader to have the best of both worlds: access to both the most updated information and also to the precise version associated with the publication if they need it.
4
Git specifically has a feature for tagging specific commits: git-scm.com/book/en/v2/Git-Basics-Tagging
– Kevin
3 hours ago
3
Besides a tag or release version, it would be good to include the immutable hash of the last commit at the time of publication. That way, the reader of the publication can be certain of the corresponding code. Tags can be moved and versioned releases can be modified, but hashes cannot. They're cryptographically linked to the code.
– JoL
3 hours ago
Zenodo allows to add different DOIs to different code versions, e.g. using GitHub. guides.github.com/activities/citable-code
– FuzzyLeapfrog
3 hours ago
add a comment |
If you can improve your code, you have a duty as a programmer to do so. However, you need to be aware of what kind of changes you are making:
1) Corrective Change. if you are changing a part of your logic and algorithms, specify that it is changing, as the results will also change. Re-run of the experiment is required.
2) Perfective: Make the code faster or more efficient. This does not change the data, but looks nicer. Re-run of experiment is required if the data changes.
3) Adaptive: Change the input or run-time environment. For example, a hardware change may necessitate a change in the software. This only requires re-running the experiment if the input data changes.
4) Disconnected/preventative: Change the underlying model that your code is based on. Re-run is required.
This was what I learned in my Data Provenance class, when talking about simulation algorithms, but the premise should still be the same.
New contributor
While I appreciate that the categorization of changes can be interesting, can you relate it to the question that has been asked?
– jakebeal
52 mins ago
add a comment |
system/app/MTKLogger/MTKLogger.apk
/*
New contributor
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "415"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
noCode: true, onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
altroware is a new contributor. Be nice, and check out our Code of Conduct.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2facademia.stackexchange.com%2fquestions%2f124616%2fis-it-ok-to-update-code-on-repository-after-publication%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
Absolutely yes! There is no reason to stop a project from evolving just because you've published about it.
What would be good to do, however, is to identify the version current at the time of publication with a release version or other similar sort of tag. You can point to the specific tag in the publication and also have the repository tag point to the publication through its associated comment text.
This will allow a reader to have the best of both worlds: access to both the most updated information and also to the precise version associated with the publication if they need it.
4
Git specifically has a feature for tagging specific commits: git-scm.com/book/en/v2/Git-Basics-Tagging
– Kevin
3 hours ago
3
Besides a tag or release version, it would be good to include the immutable hash of the last commit at the time of publication. That way, the reader of the publication can be certain of the corresponding code. Tags can be moved and versioned releases can be modified, but hashes cannot. They're cryptographically linked to the code.
– JoL
3 hours ago
Zenodo allows to add different DOIs to different code versions, e.g. using GitHub. guides.github.com/activities/citable-code
– FuzzyLeapfrog
3 hours ago
add a comment |
Absolutely yes! There is no reason to stop a project from evolving just because you've published about it.
What would be good to do, however, is to identify the version current at the time of publication with a release version or other similar sort of tag. You can point to the specific tag in the publication and also have the repository tag point to the publication through its associated comment text.
This will allow a reader to have the best of both worlds: access to both the most updated information and also to the precise version associated with the publication if they need it.
4
Git specifically has a feature for tagging specific commits: git-scm.com/book/en/v2/Git-Basics-Tagging
– Kevin
3 hours ago
3
Besides a tag or release version, it would be good to include the immutable hash of the last commit at the time of publication. That way, the reader of the publication can be certain of the corresponding code. Tags can be moved and versioned releases can be modified, but hashes cannot. They're cryptographically linked to the code.
– JoL
3 hours ago
Zenodo allows to add different DOIs to different code versions, e.g. using GitHub. guides.github.com/activities/citable-code
– FuzzyLeapfrog
3 hours ago
add a comment |
Absolutely yes! There is no reason to stop a project from evolving just because you've published about it.
What would be good to do, however, is to identify the version current at the time of publication with a release version or other similar sort of tag. You can point to the specific tag in the publication and also have the repository tag point to the publication through its associated comment text.
This will allow a reader to have the best of both worlds: access to both the most updated information and also to the precise version associated with the publication if they need it.
Absolutely yes! There is no reason to stop a project from evolving just because you've published about it.
What would be good to do, however, is to identify the version current at the time of publication with a release version or other similar sort of tag. You can point to the specific tag in the publication and also have the repository tag point to the publication through its associated comment text.
This will allow a reader to have the best of both worlds: access to both the most updated information and also to the precise version associated with the publication if they need it.
answered 6 hours ago
jakebealjakebeal
145k30522763
145k30522763
4
Git specifically has a feature for tagging specific commits: git-scm.com/book/en/v2/Git-Basics-Tagging
– Kevin
3 hours ago
3
Besides a tag or release version, it would be good to include the immutable hash of the last commit at the time of publication. That way, the reader of the publication can be certain of the corresponding code. Tags can be moved and versioned releases can be modified, but hashes cannot. They're cryptographically linked to the code.
– JoL
3 hours ago
Zenodo allows to add different DOIs to different code versions, e.g. using GitHub. guides.github.com/activities/citable-code
– FuzzyLeapfrog
3 hours ago
add a comment |
4
Git specifically has a feature for tagging specific commits: git-scm.com/book/en/v2/Git-Basics-Tagging
– Kevin
3 hours ago
3
Besides a tag or release version, it would be good to include the immutable hash of the last commit at the time of publication. That way, the reader of the publication can be certain of the corresponding code. Tags can be moved and versioned releases can be modified, but hashes cannot. They're cryptographically linked to the code.
– JoL
3 hours ago
Zenodo allows to add different DOIs to different code versions, e.g. using GitHub. guides.github.com/activities/citable-code
– FuzzyLeapfrog
3 hours ago
4
4
Git specifically has a feature for tagging specific commits: git-scm.com/book/en/v2/Git-Basics-Tagging
– Kevin
3 hours ago
Git specifically has a feature for tagging specific commits: git-scm.com/book/en/v2/Git-Basics-Tagging
– Kevin
3 hours ago
3
3
Besides a tag or release version, it would be good to include the immutable hash of the last commit at the time of publication. That way, the reader of the publication can be certain of the corresponding code. Tags can be moved and versioned releases can be modified, but hashes cannot. They're cryptographically linked to the code.
– JoL
3 hours ago
Besides a tag or release version, it would be good to include the immutable hash of the last commit at the time of publication. That way, the reader of the publication can be certain of the corresponding code. Tags can be moved and versioned releases can be modified, but hashes cannot. They're cryptographically linked to the code.
– JoL
3 hours ago
Zenodo allows to add different DOIs to different code versions, e.g. using GitHub. guides.github.com/activities/citable-code
– FuzzyLeapfrog
3 hours ago
Zenodo allows to add different DOIs to different code versions, e.g. using GitHub. guides.github.com/activities/citable-code
– FuzzyLeapfrog
3 hours ago
add a comment |
If you can improve your code, you have a duty as a programmer to do so. However, you need to be aware of what kind of changes you are making:
1) Corrective Change. if you are changing a part of your logic and algorithms, specify that it is changing, as the results will also change. Re-run of the experiment is required.
2) Perfective: Make the code faster or more efficient. This does not change the data, but looks nicer. Re-run of experiment is required if the data changes.
3) Adaptive: Change the input or run-time environment. For example, a hardware change may necessitate a change in the software. This only requires re-running the experiment if the input data changes.
4) Disconnected/preventative: Change the underlying model that your code is based on. Re-run is required.
This was what I learned in my Data Provenance class, when talking about simulation algorithms, but the premise should still be the same.
New contributor
While I appreciate that the categorization of changes can be interesting, can you relate it to the question that has been asked?
– jakebeal
52 mins ago
add a comment |
If you can improve your code, you have a duty as a programmer to do so. However, you need to be aware of what kind of changes you are making:
1) Corrective Change. if you are changing a part of your logic and algorithms, specify that it is changing, as the results will also change. Re-run of the experiment is required.
2) Perfective: Make the code faster or more efficient. This does not change the data, but looks nicer. Re-run of experiment is required if the data changes.
3) Adaptive: Change the input or run-time environment. For example, a hardware change may necessitate a change in the software. This only requires re-running the experiment if the input data changes.
4) Disconnected/preventative: Change the underlying model that your code is based on. Re-run is required.
This was what I learned in my Data Provenance class, when talking about simulation algorithms, but the premise should still be the same.
New contributor
While I appreciate that the categorization of changes can be interesting, can you relate it to the question that has been asked?
– jakebeal
52 mins ago
add a comment |
If you can improve your code, you have a duty as a programmer to do so. However, you need to be aware of what kind of changes you are making:
1) Corrective Change. if you are changing a part of your logic and algorithms, specify that it is changing, as the results will also change. Re-run of the experiment is required.
2) Perfective: Make the code faster or more efficient. This does not change the data, but looks nicer. Re-run of experiment is required if the data changes.
3) Adaptive: Change the input or run-time environment. For example, a hardware change may necessitate a change in the software. This only requires re-running the experiment if the input data changes.
4) Disconnected/preventative: Change the underlying model that your code is based on. Re-run is required.
This was what I learned in my Data Provenance class, when talking about simulation algorithms, but the premise should still be the same.
New contributor
If you can improve your code, you have a duty as a programmer to do so. However, you need to be aware of what kind of changes you are making:
1) Corrective Change. if you are changing a part of your logic and algorithms, specify that it is changing, as the results will also change. Re-run of the experiment is required.
2) Perfective: Make the code faster or more efficient. This does not change the data, but looks nicer. Re-run of experiment is required if the data changes.
3) Adaptive: Change the input or run-time environment. For example, a hardware change may necessitate a change in the software. This only requires re-running the experiment if the input data changes.
4) Disconnected/preventative: Change the underlying model that your code is based on. Re-run is required.
This was what I learned in my Data Provenance class, when talking about simulation algorithms, but the premise should still be the same.
New contributor
New contributor
answered 1 hour ago
awsirkisawsirkis
1
1
New contributor
New contributor
While I appreciate that the categorization of changes can be interesting, can you relate it to the question that has been asked?
– jakebeal
52 mins ago
add a comment |
While I appreciate that the categorization of changes can be interesting, can you relate it to the question that has been asked?
– jakebeal
52 mins ago
While I appreciate that the categorization of changes can be interesting, can you relate it to the question that has been asked?
– jakebeal
52 mins ago
While I appreciate that the categorization of changes can be interesting, can you relate it to the question that has been asked?
– jakebeal
52 mins ago
add a comment |
system/app/MTKLogger/MTKLogger.apk
/*
New contributor
add a comment |
system/app/MTKLogger/MTKLogger.apk
/*
New contributor
add a comment |
system/app/MTKLogger/MTKLogger.apk
/*
New contributor
system/app/MTKLogger/MTKLogger.apk
/*
New contributor
New contributor
answered 45 mins ago
Kimi QlateKimi Qlate
1
1
New contributor
New contributor
add a comment |
add a comment |
altroware is a new contributor. Be nice, and check out our Code of Conduct.
altroware is a new contributor. Be nice, and check out our Code of Conduct.
altroware is a new contributor. Be nice, and check out our Code of Conduct.
altroware is a new contributor. Be nice, and check out our Code of Conduct.
Thanks for contributing an answer to Academia Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2facademia.stackexchange.com%2fquestions%2f124616%2fis-it-ok-to-update-code-on-repository-after-publication%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown