Closed Bug 628634 Opened 13 years ago Closed 13 years ago

Give credit to all contributors of an article

Categories

(support.mozilla.org :: Knowledge Base Software, task)

task
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED
2011-07-12

People

(Reporter: atopal, Assigned: rrosario)

References

Details

scenario:
A localizes an article halfway through and saves it (currenty: submits for review). B takes up from where A left the article, by basing his edit on A's article. B finishes the article; it's then reviewed and published.

Problem: A doesn't get any credit for his work

Expected: Whenever you click on "edit article based on this version" we should carry forward the editors of that version and when the article is reviewed, all former contributors should be listed under the article.

Why: For one, it's the right thing to give people credit for their work. But even more important: Our licence mandates that we let people know about the contributors (attribution)
It's easy if we just take all creators of any not-explicitly rejected revision. Is that acceptable?
That would also include people whose contributions were just not considered, but I guess it would satisfy the requirements of the licence. Can we go with your solution for the short term and leave this open for a time when we have more time than we need? ;)
In the meantime, if that's not OK, we need to define an algorithmic way of calculating who the contributors that should be listed are, or decide to just make it a manually edited list. (Maybe automatically adding people when they're revisions are approved.)
actually, that's a pretty good way to go. With the Karma system we would give locale leader ways to reward people for their work, and this could be one part of it. In that sense, making it manual is even better than having an algorithmic decide.
So for implementation: This is a many-to-many relationship between Document <-> User. When a new revision is approved, add the users with non-rejected revisions in previously_approved < x <= newly_approved.

We also need UI for editing the list. Maybe something like the tag adding/dropping UI?
Target Milestone: --- → 2011Q2
Can we get this done faster if we split off a ui for manually editing the list?

Also, I think we should give credit to authors of rejected revisions if an approved revision was based off of their rejected revision. Example: Kadir edits an article. I review his edit and reject it because it has a typo. Then I create a new revision based on his rejected revision and I fix the typo. Subsequently, my revision gets approved. Both Kadir and I should get credit.
(In reply to comment #7)
> Can we get this done faster if we split off a ui for manually editing the
> list?

I'm not sure what you mean.

> Also, I think we should give credit to authors of rejected revisions if an
> approved revision was based off of their rejected revision. Example: Kadir
> edits an article. I review his edit and reject it because it has a typo.
> Then I create a new revision based on his rejected revision and I fix the
> typo. Subsequently, my revision gets approved. Both Kadir and I should get
> credit.

That's starting to get really quite complex. Can't you just manually add Kadir in that case? Or instead of rejecting it, just not review it?
(In reply to comment #8)
> (In reply to comment #7)
> > Can we get this done faster if we split off a ui for manually editing the
> > list?
> 
> I'm not sure what you mean.
> 
I was just reading though the bug and saw that in comment 3 it was suggested that we add a way to manually edit the list of credits. I like that idea but I think that's a "nice to have" feature that seems like it a lot more work than the original proposal. But really I'm just guessing. :)


> > Also, I think we should give credit to authors of rejected revisions if an
> > approved revision was based off of their rejected revision. Example: Kadir
> > edits an article. I review his edit and reject it because it has a typo.
> > Then I create a new revision based on his rejected revision and I fix the
> > typo. Subsequently, my revision gets approved. Both Kadir and I should get
> > credit.
> 
> That's starting to get really quite complex. Can't you just manually add
> Kadir in that case? Or instead of rejecting it, just not review it?

We could leave it unreviewed if both get credit like suggested in comment 1. The only thing (and this is minor) is that the reviewer is actually doing the work of reviewing the edit and rejecting it (maybe for just a typo) even though they don't click the "review" button. So it would be good if our credit process worked in this case too.
(In reply to comment #9)
> I like that idea but
> I think that's a "nice to have" feature that seems like it a lot more work
> than the original proposal. But really I'm just guessing. :)

I think it's actually strictly necessary, not "nice to have," since we don't have article history before the Kitsune conversion--there's no way to credit authors who contributed in the past.

Also, it's a lot simpler than trying to work out every scenario in which someone needs to be added to the list.

> We could leave it unreviewed if both get credit like suggested in comment 1.
> The only thing (and this is minor) is that the reviewer is actually doing
> the work of reviewing the edit and rejecting it (maybe for just a typo) even
> though they don't click the "review" button. So it would be good if our
> credit process worked in this case too.

So we need to include everyone who reviews a revision of the document?


I think at this point the only reasonable solution is a list of contributors for each article, not something we automatically calculate from the history--we can automatically try to figure out who to add at approval-time, but it will save a lot of time and headache if we can try to make that as simple as is reasonable and make it possible to add or remove people manually. Now that we've got Ricky's work with the user autocomplete stuff, that's pretty cheap.
According to me, the solution in comment 1 is enough. A reviewer must be careful to not reject a revision that adds some value to an article, even if there is typo or missing things. He/She must let it unreviewed.
See https://support.mozilla.com/en-US/kb/Keyboard%20shortcuts/history
Assignee: nobody → rrosario
With the private messaging feature this would work rather well I'd guess. Even now, I don't want to reject a revision just because there are some spelling mistakes. 

With private messaging I could click the button next to the name of the person during the review process and send them a message about my prosed fixes, so they can fix them and I can review the improved version.

(In the future we might want to change the review process to allow in-document comments and an automatic connection to the article's forum, with a message to the original author, and than the discussion about the review could happen there, just like bugzilla does it for bugs now.)
(In reply to comment #12)
> With private messaging I could click the button next to the name of the
> person during the review process and send them a message about my prosed
> fixes, so they can fix them and I can review the improved version.
First, there is already the thread for that. Then, if it not only typo, it is shorter for a reviewer to do the edit than to show the editor what we think it is good to add.
See:
https://support.mozilla.com/en-US/kb/Firefox%20does%20not%20ask%20to%20save%20tabs%20and%20windows%20on%20exit/history
So comment 1 is definitively the solution.
We went with comment 1 + manual override. When new revisions are approved, the creators of the approved and any new unapproved revisions are added to the contributors list.

The list of contributors now shows below the history and can be edited by users with the 'wiki.change_document' permission.

There is a management command (`manage.py init_contributors`) that needs to be run to get the contributor lists initialized based on the existing revisions. I'll file a bug to run this on stage.

https://github.com/jsocol/kitsune/commit/f1ebb241e4b1d746f97686e65f49e478e28d89f2
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Target Milestone: 2011Q2 → 2011-07-12
FYI, init_contributors was run on stage and I see the contributors now.
Verified contributors list updates with [only] approved new revisions.
Status: RESOLVED → VERIFIED
Blocks: 679704
You need to log in before you can comment on or make changes to this bug.