How do you cite an organization with the new Mendeley Reference Manager?
In order to have the full name of the organization in the Bibliography (e.g. Swiss National Bank) and the abbreviation (e.g. SNB) in the citation?
This question is related to this one:
Cite Institutional Author in Mendeley
and this answer:
https://stackoverflow.com/a/58584963/18988624
-> However, they provide a solution for the old Mendeley Desktop version, thus I was wondering if there exists a new approach for the new Mendeley Reference Manager?
Related
What is the container of repositories called? I can create one of these and then add 1 or more repositories to it.
I checked the GitHub glossary (link below) and it is not clear to me whether or not this is called an "Organization" or "Project".
https://help.github.com/articles/github-glossary/
In the GitHub terminology, a repository belongs either to a user account, or to an organization account.
So the direct answer to your question is "organization".
For example, the repository https://github.com/vuejs/vue.git corresponds to the the vuejs organization that hosts the vue software (that actually corresponds to the Vue.js framework).
As an aside, I usually find myself speaking of a "project" as a synonymous of a Git repository. However, note that the "Projects" keyword mentioned in the GitHub page (cf. the screenshot below) actually refers to a set of Kanban boards.
Software packages are often shipped with changelog and/or release notes. What's the difference between them? Should they be both included with release of a new version?
To directly answer your question, you can include both in your software release.
Release notes are a set of documents delivered to customers with the intent to provide a verbose description of the release of a new version of a product or service. These artifacts are generally created by a marketing team or product owner and contain feature summaries, bug fixes, use cases, and other support material. The release notes are used as a quick guide to what changed outside of the user documentation.
Conversely, changelogs are comprehensive lists of the new features, enhancements, bugs, and other changes in reverse chronological order. Changelogs usually link to specific issues or feature requests within a change management system and also may include links to the developer who supplied the change.
Yes I think you can include both on a new release.
For me the main difference is that in a release note you can explain what is new or what have changed in a more comprehensive language.
In the case of a changelog you have to add more technical details of the changes, for example with commit messages with link to the diff or PRs with links to the technical discussion.
If two people are working on the same EAP file and later want to merge it. Can they do it?
Is it possible to merge two EAP files?
My original, accepted answer: (also note the 2018 update below)
Have a look at this manual section:
http://www.sparxsystems.com/enterprise_architect_user_guide/projects_and_teams/teamdevelopment.html
As with all collaboration, there is a chance for raising conflicts when more that one person works on the same data.
From EA's side the most straightforward approach is the XMI transfer (import/export).
If you collaborate on a regular basis you might want to setup more advanced version control. (see above weblink) Careful, the feature availability depends on the EA version that you use.
As pointed out here it is possible for small teams to access and work on the exact same file on the FS.
Update from 2018:
The user guide has been updated and is available through new URLs. The current user guide page now differentiates methods for
network deployment of EA files
Replication (including a sub-page that also deals with resolving merge conflicts)
XMI Export / Import
In the meanwhile there is a 3rd party solution of LieberLieber avbailable, the Model Versioner, with which you can diff and merge EAP files on the model level:
https://lemontree.lieberlieber.com
A friend recently had the occasion for a legal name change, which made me wonder about how to cope with that in a development environment, especially in regards to source control.
Their legal name changed, so naturally their login name and associated identity stuff changed. If they were a team member of mine, I'd like to change the record of their past commits to the project to be consistent with their new name. Is that possible in Mercurial? In other version control systems?
See the ConvertExtension. It can be used to do a Mercurial-to-Mercurial database conversion. Specifically, see the --authors switch to remap author names.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 7 years ago.
Improve this question
Assume I own some open source project with no license information. Furthermore, assume nobody has contributed publicly yet and so I own the project's source code and copyright.
Say the source code is already hosted online. If I decide to give it an open source license by uploading the associated COPYING document to the repository and adjusting the source files accordingly, will the previous versions of the project become licensed as well? Or will the current and future versions be protected while previous versions fall under public domain?
Alternatively, say I start a new project using a DVCS (e.g. Mercurial) on my local machine. I commit all my changes (locally) and then add license information in a later changeset. If I were to host the project/repository, will the entire history be licensed or only the versions following that changeset?
In (2), the project is initially not hosted so this does not seem like a problem. But once it's uploaded, some of the project's history will not include the license information, making the result look almost exactly like (1).
I ask because Google Code allows you to select a license on a new project, even if you intend to import the repository afterward, making licensing seem somewhat external to the actual source code, whereas bitbucket.org does not.
If you want the license to apply to the whole history, just say so in the license file, something like 'This file was added at revision x, but you may consider that the license applies to all revisions prior to x as well'.
You can view it as the license declaring what it covers... legalbol is code, scoping can be made explicit if you want.
As long as you're not using any GPL libraries then what you do with your code is up to you. You can say that you code is retroactively GPL or you can say what version is GPL and what version is BSD and what version is Apache license. You can even offer dual license: use GPL or pay me $100 to use BSD (kind of like what the Qt guys did before they decided to offer LGPL).
Now, if you are using a GPL licensed library then your code is already GPL.
I'm not a lawyer but as far as I know code or any form of content being plainly on the web doesn't really make it public domain.
Regarding the timing of your license: If you attach a license to your code in revision 100, this should only affect revision 100 and future changesets until you change that license again. Otherwise you could, for example, revert code from being opensource afterwards.
From my understanding the license that you get when checking out some code (with a given revision) is the license applicable to that revision of the project. IMO this is also what makes forks from projects possible that went from some OSI-license to a closed one using the opensource code.
Consequently, you should probably create a new repo with the license information in place before putting it online.
Why do you want to expose the source history? The easiest solution to your scenario is to simply copy your code and create a brand new repository, then post this new repository somewhere, along with an open source license. Pull the source that is currently hanging out online without a license, and you're golden. The old source and the new source are completely separate and there shouldn't be any problems. If someone has a copy of the old source, you probably can't do anything to stop them from doing whatever they want with it, but you've got a clean slate for everything going forward. Anything pulled from your new repo (the one with the license) will be covered by that license.
I'm assuming that you are the author of the source that is currently hosted online. If you're not, then you've got other issues to contend with, namely, whether or not you have the right to specify a license for someone else's source code - probably not.
If you use LGPL (or Apache or Berkeley-Licensed) code you're better off then using GPL code which requires that all code which is written based on this code has to be published as open source.
See http://www.google.com/help/faq_codesearch.html#license, but you may get better information regarding Google code from this source.