search

jlegewie / zotfile

Zotero plugin to manage your attachments: automatically rename, move, and attach PDFs (or other files) to Zotero items, sync PDFs from your Zotero library to your (mobile) PDF reader (e.g. an iPad, Android tablet, etc.), and extract PDF annotations.
4.06k stars 282 forks source link

Is this project dead? Last commit almost a year ago #522

Open adam-ah opened 3 years ago

adam-ah commented 3 years ago

I see a lot of open issues and pull requests just hanging there without any feedback from the maintainer(s).

The last commit is also really old (on 12 Aug 2020)

Is this project dead? Should we add more maintainer(s) to keep it alive?

sojusnik commented 3 years ago

Zotfile could very soon become more or less obsolete, at least the annotation extraction feature, because Zotero finally integrates a PDF reader with with all the bells and whistles, as announced here and here.

jlegewie commented 3 years ago

Good question! The unfortunate answer is that I won't have any time to invest in the development in the foreseeable future. As @sojusnik says, there are some good news as well: Zotero is beta testing a new version right now that implements at least one of the key features of zotfile (extraction PDF annotation) and will make another obsolete for many but not all users (sending PDF to the tablet). These are very exciting developments and I am happy it's finally happening!

My guess is that it will be hard to add maintainers. It's a big task for someone who is not familiar with the code base.

argenos commented 3 years ago

I haven't tested the beta yet, but I think that there will be a trade-off for most users here: Annotating with the new PDF features probably requires that you store the PDFs in Zotero's DB (not as linked attachments), and counts towards your storage limit (300 MB free). Zotfile's attachment management menu has allowed a lot of us to store wherever we want (and having sensible renaming rules!) and sync/backup our attachments with the cloud of our choice. I haven't seen this mentioned in the current Zotero beta (it might be addressed later on though).

Edit: Going through the beta thread, it seems it does support linked attachments. Not sure exactly how that works, but at least part of my point still stands: I want rules to rename my files and the choice to sync with my own cloud, and as far as I know there are no core features that do that yet.

argenos commented 3 years ago

I took a little time to set up a profile to test with the beta over the weekend, and I have to say, I am unimpressed by the annotation extraction as of now. The main limitations I found:

The one nice thing I found was the image-style clipping.

Other things missing that Zotfile offers:

I understand the appeal for some to have everything under a single app (Zotero), but the viewing/annotating experience is still very limited and any PDF viewer can do a lot more. I assume this will get better with time, but for now I'm not convinced.

notuntoward commented 3 years ago

Yes, the new annotator won't (as far as I can tell) do what zotfile does for me now: put all my pdfs in one directory, with a name matching a bibtex key coming from BetterBibtex.

zhiyuanzhai commented 3 years ago

It's good to see Zotero having an iPadOS version coming. But I still prefer to read on a 3rd-party PDF reader (PDF Expert, Marginnote, etc. There are so many great apps on iPad for PDF reading!) and leave all document management works on my Mac, where I have a full TeXLive installed. I really wish this project could continue even after Zotero on iPadOS were released.

vancleve commented 3 years ago

My guess is that it will be hard to add maintainers. It's a big task for someone who is not familiar with the code base.

Would you be open to it though? An opportunity that could be advertised to the Zotero community?

jlegewie commented 3 years ago

In theory, yes. But it also depends on how much work it is for me.

adam-ah commented 3 years ago

@jlegewie, I'm not too sure I understand your concern. The project is essentially dead, why don't you just hand over it to the community to work on it? The last stable release can be made available (your last version), and from there on, the community can add to it / modify it the way they see fit.

If you are concerned that it's your repo, then at least you can add an announcement that from now on this other fork is the active version, and point to the community maintained version.

I don't think it's fair to say you don't have time to work on it, and no one else should be allowed to work on it either?

EDIT:

I just had a look at the whole codebase, and it's only 51,797 lines of JS code.

However, excluding the PDFJS library, which was just dropped into a subfolder, the actual codebase is 4834 lines of JS code.

jlegewie commented 3 years ago

Sorry @adam-ah but I find your attitude offensive. It conveys an entitlement to 100s of hours of work that someone else has put into the project and shared freely over many years.

Let me clarify my position:

1) Zotfile is open source under the GNU General Public License, version 3.0 license. All the code is publicly available. Anyone can create a fork, work on it, modify the code, share any changes and publish a new plugin as long as you follow the license terms. That has always been the case (or at least since I put it on GitHub over 10 years ago). If that is what you want, I don’t know what you are complaining about.

2) Of course, that is not the same as handing over control of jlegewie/zotfile and allowing others to push changes to the existing user base. In my view, that does require one or multiple maintainers who invest time in the project and are committed to it even with community support. I am only willing to do that when I have the impression that someone has the knowledge and commitment, and at least partly shares my ideas of what makes sense for the future of the project. Such a transition takes time and does require work on my part. Anything else would be irresponsible because I essentially hand over the right to install software on the computer of 1,000s of people.

And by the way, zotfile is bundled with a modified version of PDF.js.

adam-ah commented 3 years ago

Anyone can create a fork, work on it, modify the code, share any changes and publish a new plugin as long as you follow the license terms. That has always been the case (or at least since I put it on GitHub over 10 years ago). If that is what you want, I don’t know what you are complaining about.

I already covered this before, in accordance with @vancleve's suggestion:

If you are concerned that it's your repo, then at least you can add an announcement that from now on this other fork is the active version, and point to the community maintained version.

To summarise, you don't want to work on it, and no one else can work on it because it would need your involvement and you don't want to be involved (see the many open but never reviewed/accepted pull requests to this repo).

argenos commented 3 years ago

you don't want to work on it, and no one else can work on it because it would need your involvement and you don't want to be involved (see the many open but never reviewed/accepted pull requests to this repo).

@adam-ah I am a bit confused by this. If you want to work on it, there is no real reason you can't. Why not merge those open PRs into your fork? Before making such an announcement to the community, it would make more sense, in my opinion, to demonstrate that you're willing to maintain a new fork (and hence have good-enough knowledge about the code base). Otherwise we might run into a situation where announce these changes based on the word of the new maintainer(s) and it doesn't work out for any number of reasons. Maintaining a plugin with these many users is a huge commitment, and it's hard to know beforehand how much time you'll need, how many people will help, etc.

jlegewie commented 3 years ago

you don't want to work on it, and no one else can work on it because it would need your involvement and you don't want to be involved (see the many open but never reviewed/accepted pull requests to this repo).

@adam-ah I am a bit confused by this. If you want to work on it, there is no real reason you can't. Why not merge those open PRs into your fork? Before making such an announcement to the community, it would make more sense, in my opinion, to demonstrate that you're willing to maintain a new fork (and hence have good-enough knowledge about the code base). Otherwise we might run into a situation where announce these changes based on the word of the new maintainer(s) and it doesn't work out for any number of reasons. Maintaining a plugin with these many users is a huge commitment, and it's hard to know beforehand how much time you'll need, how many people will help, etc.

👆 Completely agree with @argenos. And for clarity, I am happy to support an announcement on the zotfile website and even in zotfile itself but there should first be a fork that shows regular work. Start with a fork, create a plugin, announce it here and on the zotero forum. You will get some users through that and then we can think about an "official" announcement. And again, I am not opposed to adding a maintainer to jlegewie/zotfile but it has to be the right person. Someone who has been active in the zotero community maybe even with experience developing plugins would be a good fit.

In any case, do not underestimate the time commitment. Even with community support and pull requests from other members, you have to review them and make sure that they are not introducing any bugs. You also have to maintain additional features over time when the original contributor is not around anymore.

So the notion "you don't want to work on it, and no one else can work on it" is just ridiculous.

wohenbushuang commented 2 years ago

The reply of #543 took me here.

I read the mentioned links furthermore, and notice that #330 was created in 2018 and recieves no feedbacks so far. Actually if it has been merged or even replied in these years, I won't need to translate again myself and all people will enjoy the translation out-of-box.

I saw the similar complaint under the forked repo's issue, and on this point, I partially agreed with "you don't want to work on it, and no one else can work on it". Not everyone want to be a maintainer, that's why PR contribution from community function exists. I take pity on the #330 contributor in 2018, the feeling not obtain any response in months sucks indeed, as I just experienced.

Even with community support and pull requests from other members, you have to review them and make sure that they are not introducing any bugs.

Specifically, for the translation PR, can I understand as that you need to learn the target translation language first, and then will start to review and make sure its correctness? Just a kidding, so why not try to reply PR with what you are thinking: just read, appreciation, need further test, won't fix, and so on?

zhiyuanzhai commented 2 years ago

@jlegewie Now the real problem is that without a proper maintainer, there’s technically nothing we can do to contribute to this project, since none of our PRs will be merged without a permission of a proper maintainer.

JohnAtl commented 2 years ago

As has been said repeatedly, fork it and be the maintainer. You don’t have to wait for someone else to do the work, you can do it.