migrating -contrib to -extras

[Michael Bishop]

Habari-extras repo is now functional, and a few questions arose
today. First, should versioning be preserved in moving from the gcode
repo?

Second, are all items in extras going to be strictly attributed to
Community, with no individual credits. Owen brought up, "It also
helps keep the license valid. If you're tracking all contributors
because of license requirements, that's a great place to do it, I
think." (This was more specifically to the notion of being able to
have more than one author credit in the plugin itself).

Finally, how will downloadable versions of the plugins/themes be made
available on hp.o. We still need to have that latest dev release as a
download, so that dove tails into the extras question.

Also how will we handle bug/enhancement tickets. Currently habari-
extras doesn't have a way to view/create tickets. Will all tickets be
handled in the main issue tracker? I'd suggest keeping them separate,
to keep the core code issues easier to monitor.

thoughts?

~milkb

[Scott Merrill]

> Habari-extras repo is now functional, and a few questions arose
> today. First, should versioning be preserved in moving from the gcode
> repo?

I don't think it's terribly important to retain versioning on what
little currently exists. If the individual authors want to do so,
they should of course feel free; but I don't think it's something we
should mandate.

> Second, are all items in extras going to be strictly attributed to
> Community, with no individual credits. Owen brought up, "It also
> helps keep the license valid. If you're tracking all contributors
> because of license requirements, that's a great place to do it, I
> think." (This was more specifically to the notion of being able to
> have more than one author credit in the plugin itself).

I think it makes the most sense to give attribution to the community.
The SVN commit log will maintain individual contributions, if that
ever becomes an issue for someone. But my understanding was that
anyone with commit access to -extras could conceivably make changes to
anything in the -extras repository. As such, I make make gigantic
changes to your theme. Should you get the public credit? Should I?
By crediting "the Habari Community", we sidestep some of those power
plays, and we reinforce the notion that from the community comes great
stuff.

> Finally, how will downloadable versions of the plugins/themes be made
> available on hp.o. We still need to have that latest dev release as a
> download, so that dove tails into the extras question.

The core Habari repository can easily be made into a tarball with
something like this in a post-commit hook:
svn export /path/to/repo /path/to/export;
cd /path/to/export;
tar zcf /path/to/downloads/habari-latest.tar.gz *;

We could do the same for -extras, so that the latest version is always
packaged. The real question is: should we provide individual tarballs
/ zipfiles for the individual components in the repository, or should
we only provide a single habari-extras.tar.gz download containing
everything?

> Also how will we handle bug/enhancement tickets. Currently habari-
> extras doesn't have a way to view/create tickets. Will all tickets be
> handled in the main issue tracker? I'd suggest keeping them separate,
> to keep the core code issues easier to monitor.

We have a trac installation for -extras, I think we should use it for
issue tracking. We can also use the wiki there for documentation of
the individual components.

[Owen Winkler]

Michael Bishop wrote:
> Habari-extras repo is now functional, and a few questions arose
> today. First, should versioning be preserved in moving from the gcode
> repo?

I think this is an all-or-nothing prospect that has already passed us by
if there is revision history in the subversion database. That said, I
think there isn't so much in there to be too concerned about preserving
the versioning.

> Second, are all items in extras going to be strictly attributed to
> Community, with no individual credits. Owen brought up, "It also
> helps keep the license valid. If you're tracking all contributors
> because of license requirements, that's a great place to do it, I
> think." (This was more specifically to the notion of being able to
> have more than one author credit in the plugin itself).

I think that it's fine if people want to attribute code to the
community, but I also think that there must be a place for recognition
somewhere in our project.

Granted, I agree completely with keeping names out of individual
components of the core code, and I likewise concur with doing the same
for contributed code (such as adding code comments that say "this
line/function was added by so-and-so"). Still, copyright attribution
should be maintained for the contributors, and I see no good reason why
this information couldn't exist in the place that is meant to hold it -
the plugin info record.

Being that the revision log will likely not distributed with the plugin,
leaving the subversion log as the sole record of contribution will
likely not distribute proper copyright attribution or recognition with
the conventional zip or tar file as including actual names in a specific
place in the plugin.

It should be up to contributors to include their own attribution
information in the plugin info. If you leave that out of your commit,
then you don't get it unless someone adds it for you.

Assignment of attribution is less of an issue to me than committing
referral links in themes and other spurious practices against which we
should have strict rules. Also, attribution is of less concern to me
than stating an explicit license for the code, which should be ASL if
we're keeping in our repo, with the understanding that committing code
there allows community access to edit it.

> Finally, how will downloadable versions of the plugins/themes be made
> available on hp.o. We still need to have that latest dev release as a
> download, so that dove tails into the extras question.

A post-commit hook already is connected to the main repo to create
"nightlies" (which are actually immediately in-sync with the repo) of
the core distribution here: http://habariproject.org/dist/habari_head.zip

We could provide a similar functionality for plugins and themes within
the repo.

There is curerntly no branching or tagging in the extras repo. Is this
intentionally omitted, or was some other plan in place to deal with that?

> Also how will we handle bug/enhancement tickets. Currently habari-
> extras doesn't have a way to view/create tickets. Will all tickets be
> handled in the main issue tracker? I'd suggest keeping them separate,
> to keep the core code issues easier to monitor.

I can edit the Trac instance to enable that feature. I think that the
separate repo should have its own Trac to keep the noise level down on
the main repo.

Owen

[Michael Bishop]

On Jan 17, 8:19 pm, Owen Winkler <epit...@gmail.com> wrote:
> Michael Bishop wrote:
> > Habari-extras repo is now functional, and a few questions arose
> > today. First, should versioning be preserved in moving from the gcode
> > repo?
>
> I think this is an all-or-nothing prospect that has already passed us by
> if there is revision history in the subversion database. That said, I
> think there isn't so much in there to be too concerned about preserving
> the versioning.

So it'd be safe for me to just export the contrib repo and commit to
extras? Skippy mentions "individual authors", which there are none,
they are all "Community" plugins. Which leads to the second
question... (of which I have no further for, I'll hope others chime
in. I am also not concerned personally with attribution, just think
it should be completely fleshed out now)

> Assignment of attribution is less of an issue to me than committing
> referral links in themes and other spurious practices against which we
> should have strict rules. Also, attribution is of less concern to me
> than stating an explicit license for the code, which should be ASL if
> we're keeping in our repo, with the understanding that committing code
> there allows community access to edit it.

Are you saying even extras? So if I have a theme that's based on a CC
licensed template, it can't be added?

>
> > Finally, how will downloadable versions of the plugins/themes be made
> > available on hp.o. We still need to have that latest dev release as a
> > download, so that dove tails into the extras question.
>
> A post-commit hook already is connected to the main repo to create
> "nightlies" (which are actually immediately in-sync with the repo) of
> the core distribution here: http://habariproject.org/dist/habari_head.zip
>
> We could provide a similar functionality for plugins and themes within
> the repo.
>
> There is curerntly no branching or tagging in the extras repo. Is this
> intentionally omitted, or was some other plan in place to deal with that?
>

That was another question I meant to ask. contrib never had branches/
tags so something would need to be put in place to accommodate
working code as well as work-in-progress.

I think individual download files should be provided. I can see the
distro growing quickly, and not everyone wants to download 50 plugins/
themes when they want/need just one. Plus, versioning might be a
problem with the single download approach.

>
> I can edit the Trac instance to enable that feature. I think that the
> separate repo should have its own Trac to keep the noise level down on
> the main repo.

Thanks.

~milkb

[Sean T Evans]

On Thu, 2008-01-17 at 20:19 -0500, Owen Winkler wrote:
> Michael Bishop wrote:

> > Also how will we handle bug/enhancement tickets. Currently habari-
> > extras doesn't have a way to view/create tickets. Will all tickets be
> > handled in the main issue tracker? I'd suggest keeping them separate,
> > to keep the core code issues easier to monitor.
>
> I can edit the Trac instance to enable that feature. I think that the
> separate repo should have its own Trac to keep the noise level down on
> the main repo.
>
> Owen

My fear is that by placing a strong line between plugin/theme
downloading/bug tracking etc. we run the risk of relegating these things
to second-class status. If we share a bug tracking system between core
and plugins/themes that keeps many eyes on them, and hopefully will
reduce the "real developer" vs. "plugin/theme developer" gap.

Although it would create a much more... vibrant trac system, I think
from the perspective of building community, the benefit outwheighs the
extra work.

--
Sean T Evans

[Morydd]

The subject of licensing for -extras came up again today in IRC, so it
was suggested that it be brought up again on the mailing list.

Here are a couple thoughts that came to mind while thinking about it.
If code is credited to the community, does the Habari community then
become responsible (from a legal perspective) for making sure that the
code is licensed properly? If someone modifies a WP plugin to work
with Habari, and changes the license to something incompatible with
the original, does this open us up to liability because it's the
project's name on it?

Other than that thought, I think I'm generally in favor of allowing a
wider array of licenses if it can be done. This will give us the
ability to port more things from other platforms (ie CC-BY licensed
themes). Perhaps suggestion of requiring any license to be GPL
compatible is a good starting point.

http://www.fsf.org/licensing/licenses/

[Owen Winkler]

I think the terms for adding projects to the extras repo should be kept
reasonably simple but also address the beliefs of our community. This
is my opinion for what rules we should adhere to:

All plugins must be ASL2-licensed to be submitted to the repo.

This is a practical concern because alternative licenses may have
additional requirements that are incompatible with Habari itself or with
the idea that anyone with access to the extras repo has access to alter
any code in it.

I dislike the idea that everything must be attributed to the Habari
Project when submitted to the repo. While the ASL license on the plugin
will probably not bother someone who is already using Habari, being
unable to publish copyright information on produced plugins is a bit
strange.

We should insist that contributors who do not add their copyright
information to the plugin upon commit release their rights on the
contribution. If you want to retain copyright, it is very simple to
alter the code to add it.

At any time, any plugin can be submitted for proprietorship by the
Habari Project. At that time, the current copyright holders will be
contacted to vet their claim of ownership and release their claim to the
Habari Project. Until this happens, NO plugins should be attributed to
the Habari Project, and in reality, this should probably only happen
when a plugin is being considered for core inclusion.

Regarding themes, it is my opinion that themes must be dual-licensed.
They need a license for the code (ASL2) and a license for the output it
produces. I suggest that the output license for themes in our repo be a
Creative Commons license that requires the allowance of modifications
(to be consistent with the idea that anyone can edit the files in the repo).

Also, we should specifically note in advance that the appropriate place
for copyright placement for a theme is in the theme information file,
NOT as part of the public display of the theme. A theme in the repo
must not require the copyright or any specific author link to be
displayed or maintained in derivative works, although these may be
included part of the raw theme. The goal being that themes should
benefit the community, not constitute linkfarms for theme authors.

Plugin and theme authors that wish to fulfill commercial aspirations
would do well to contribute decent themes to the repository which would
be the easiest way to garner a reputation for quality work and
involvement with the community.

One of the goals with a central repository should be that it be THE
central repository, and we should make good efforts to keep this part of
the community from fragmenting while making sure that our property is
protected for the reuse we intended.

Owen

[Sean T. Evans]

Owen Winkler wrote:
> I think the terms for adding projects to the extras repo should be kept
> reasonably simple but also address the beliefs of our community. This
> is my opinion for what rules we should adhere to:
>
> All plugins must be ASL2-licensed to be submitted to the repo.
>
> This is a practical concern because alternative licenses may have
> additional requirements that are incompatible with Habari itself or with
> the idea that anyone with access to the extras repo has access to alter
> any code in it.
>
> I dislike the idea that everything must be attributed to the Habari
> Project when submitted to the repo. While the ASL license on the plugin
> will probably not bother someone who is already using Habari, being
> unable to publish copyright information on produced plugins is a bit
> strange.
>
> We should insist that contributors who do not add their copyright
> information to the plugin upon commit release their rights on the
> contribution. If you want to retain copyright, it is very simple to
> alter the code to add it.

"Release their rights" in what fashion? Simply their right to be
credited? Also, it seems that committing to -extras is (under current
structure) releasing rights to have any kind of control in any case, as
anyone with commit access would then be able to modify your code anyway.

> At any time, any plugin can be submitted for proprietorship by the
> Habari Project. At that time, the current copyright holders will be
> contacted to vet their claim of ownership and release their claim to the
> Habari Project. Until this happens, NO plugins should be attributed to
> the Habari Project, and in reality, this should probably only happen
> when a plugin is being considered for core inclusion.
>
> Regarding themes, it is my opinion that themes must be dual-licensed.
> They need a license for the code (ASL2) and a license for the output it
> produces. I suggest that the output license for themes in our repo be a
> Creative Commons license that requires the allowance of modifications
> (to be consistent with the idea that anyone can edit the files in the repo).

Is there a CC license that meets these requirements? I'm also not sure
that the respective licenses _don't_ cover the whole of a work. Books
don't need a separate copyright for their cover and their text. Perhaps
a bad analogy, but it seems similar to me.

> Also, we should specifically note in advance that the appropriate place
> for copyright placement for a theme is in the theme information file,
> NOT as part of the public display of the theme. A theme in the repo
> must not require the copyright or any specific author link to be
> displayed or maintained in derivative works, although these may be
> included part of the raw theme. The goal being that themes should
> benefit the community, not constitute linkfarms for theme authors.

If our policy is that the themes cannot credit the designer, are we
going to forbid links the Habari Page as well? It seems to me that to do
otherwise would be hypocritical.

> Plugin and theme authors that wish to fulfill commercial aspirations
> would do well to contribute decent themes to the repository which would
> be the easiest way to garner a reputation for quality work and
> involvement with the community.
>
> One of the goals with a central repository should be that it be THE
> central repository, and we should make good efforts to keep this part of
> the community from fragmenting while making sure that our property is
> protected for the reuse we intended.

Unfortunately it seems to me that what we're looking at doing will be
much too restrictive to allow it to become THE central repository. In
order to use -extras you will have to 1)Use our license 2)Surrender all
oversight of your work 3)Depend entirely on people reading NOTICE files
to receive any credit for your work.

I'm honestly not sure where the point of compromise is between the
openness that we desire, protecting Habari from liability for licensing
issues, and recognizing good work in whatever form it appears.

[Christian Mohn]

Was the intention of -extras ever to be the "one stop source for all plugins
Habari"? I didn't think so, but I might be wrong. I wanted access to it when
it was created to be able to put my code somewhere, and I don't see the huge
problem in assigning copyright to the Habari project. Others might see it
otherwise though, but IMO they could publish their code elsewhere besides in
any official Habari svn repository.

As for the one stop source, I think there are other methods to make that
happen without everyone having to host their code on -extras. Not sure how
it should work, but I'm sure there are ways to accomplish that.

Christian

[Michael Bishop]

On Feb 5, 6:28 pm, "Christian Mohn" <h0b...@gmail.com> wrote:
> Was the intention of -extras ever to be the "one stop source for all plugins
> Habari"? I didn't think so, but I might be wrong. I wanted access to it when
> it was created to be able to put my code somewhere, and I don't see the huge
> problem in assigning copyright to the Habari project. Others might see it
> otherwise though, but IMO they could publish their code elsewhere besides in
> any official Habari svn repository.
>
> As for the one stop source, I think there are other methods to make that
> happen without everyone having to host their code on -extras. Not sure how
> it should work, but I'm sure there are ways to accomplish that.

I don't think habari-contrib was meant for that, but now that it's at
hp.o, the idea is not to have numerous repos for plugins/themes, at
least that's my take.

~miklb
>
> Christian-----Original Message-----

[Scott Merrill]

> I think that it's fine if people want to attribute code to the
> community, but I also think that there must be a place for recognition
> somewhere in our project.

Having commit access to the -extras repository should be its own level
of recognition, in part. I mean, we can't simply grant commit access
to everyone who asks: we need some sort of vetting process.

That, or we start granting granular permissions to the repository, so
that you can only commit to your projects (which may be a good idea).

> Granted, I agree completely with keeping names out of individual
> components of the core code, and I likewise concur with doing the same
> for contributed code (such as adding code comments that say "this
> line/function was added by so-and-so"). Still, copyright attribution
> should be maintained for the contributors, and I see no good reason why
> this information couldn't exist in the place that is meant to hold it -
> the plugin info record.

If a plugin is committed to the -extras repository, and that
repository provides write access to all projects to all members,
maintaining copyright of individual projects could become problematic.
If I modify your -extra hosted plugin, I have a copyright interest in
that project now. If lots of people work collaboratively (which, I
believe, was one of the original goals for this repository), the
plugin's info field may be insufficient to properly document the
contributors.

Perhaps we require that all -extras hosted projects contain a NOTICE
file, per the Apache requirements: this makes each project more akin
to Habari itself, whereby we list contributions in this file, rather
than in the source code. This is just one idea.

> Being that the revision log will likely not distributed with the plugin,
> leaving the subversion log as the sole record of contribution will
> likely not distribute proper copyright attribution or recognition with
> the conventional zip or tar file as including actual names in a specific
> place in the plugin.

A NOTICE file could be included in generated archives.

> Assignment of attribution is less of an issue to me than committing
> referral links in themes and other spurious practices against which we
> should have strict rules. Also, attribution is of less concern to me
> than stating an explicit license for the code, which should be ASL if
> we're keeping in our repo, with the understanding that committing code
> there allows community access to edit it.

I concur. Affiliate links and linkfarm attempts should be explicitly forbidden.

I also agree that the use of the Apache license be mandatory for
-extras hosted projects.

> There is curerntly no branching or tagging in the extras repo. Is this
> intentionally omitted, or was some other plan in place to deal with that?

In Subversion, a branch works upon the entire repository from which
the branch is created. I did not create a top-level /branches
directory because I don't think we want the entire repository branched
when a single plugin branches.

We could have /trunk, /branches, and /tags directories inside the
individual project directories, with well-written documentation
explaining how to branch or tag just one project.

> > Also how will we handle bug/enhancement tickets. Currently habari-
> > extras doesn't have a way to view/create tickets. Will all tickets be
> > handled in the main issue tracker? I'd suggest keeping them separate,
> > to keep the core code issues easier to monitor.
>
> I can edit the Trac instance to enable that feature. I think that the
> separate repo should have its own Trac to keep the noise level down on
> the main repo.

Each project should then be its own component within that Trac
instance, so that reports can be filed against individual projects
within the repository, and granular reports and feeds can be
generated.

> I dislike the idea that everything must be attributed to the Habari
> Project when submitted to the repo. While the ASL license on the plugin
> will probably not bother someone who is already using Habari, being
> unable to publish copyright information on produced plugins is a bit
> strange.

If we don't make the Habari Project the "owner" of contributed
projects, how do we properly manage potentially many people with write
access to lots of disparate projects?

Do we say for individual projects "all contributions to this project
relinquish copyright to those contributions to the original author" ?
This allows the original author to maintain copyright on all their
projects' code, but potentially discourages the kind of collaborative
ecosystem we had previously envisioned.

> At any time, any plugin can be submitted for proprietorship by the
> Habari Project. At that time, the current copyright holders will be
> contacted to vet their claim of ownership and release their claim to the
> Habari Project. Until this happens, NO plugins should be attributed to
> the Habari Project, and in reality, this should probably only happen
> when a plugin is being considered for core inclusion.

What does it mean, in a legal sense, for the Habari Project to have
proprietorship and/or copyright on a contributed project?

[Michael Bishop]

So, from all of this, how would this pertain to leaving a link to the
original designer of an "open" HTML/CSS design in a theme for extras?

~miklb

[Owen Winkler]

Michael Bishop wrote:
> So, from all of this, how would this pertain to leaving a link to the
> original designer of an "open" HTML/CSS design in a theme for extras?

If the license requires only that the copyright notice remain intact,
then the rest of the theme is fair game, including any links in output.

A CC-attribution license requires that the attribution appears in a
place specified by the author. If that includes a link in the output,
then that's where the attribution needs to appear.

Personally, I'm not interested in distributing themes that require you
to link to the author on your public site. I think that the wording on
the CC-by license is poor, that there should be an alternative for
attribution that allows derivative works to include proper attribution
without keeping the link format as requested by the author.

I think themes such as this might be ok for the extras repo, but:

1) The idea of the extras repo is to build plugins and themes that might
eventually be promoted to core.
2) The core will never include a CC-by license.

So I wonder if we should bother allowing CC-by themes in the extras repo
at all.

Owen