Hi
Is there a roadmap for jabref, so what’s planned to implement in the future?
I’m especially curious if v.6.0 is still far away ans what new/improved feature(s) will be included.
The thing that comes closest to a roadmap for JabRef are its projects pages at GitHub.
If you want to know the current blockers to a release, have a look at the milestones. We usually wait for those to be fixed, before a release happens, because they are either a critical issue, or because they would be a “nice to have” for the release, but sometimes we move them to the next release, if we feel like they will not be done in time and prevent a release for too long.
For JabRef 6.0, it is planned to have an overhaul of JabRef’s search implementation. We will have to wait and see how that turns out. 
It’s done, when it’s done.
Currently the JabRef community has no set principles that we have written down and published that would explain our priorities. That is, because priorities are ever changing and what will get fixed strongly depends on the person that comes around with the knowledge and the willingness to fix an issue. You will notice that many issues that get fixed are not always the most “important” ones according to the projects page. This is unfortunate, but it just so happens that many of the most important issues are also some of the most difficult or extensive issues to solve, so not every developer or technical savvy person feels up to the task or has the knowledge and time to fix those.
I personally (and this may strongly differ from maintainer to maintainer), classify issues into some broad categories when I look over them and then decide, if they are of high, normal or low importance.
A) Is there a workaround
- yes
- no
B) Has there been or will there be a risk of dataloss (for users)?
- yes
- no
C) Does the issue prevent JabRef from working normally? (crash/error message triggered/functionality was once working but now does not work anymore (=regression))
- yes
- no
D) How many users have been or will be affected?
- many
- not many
E) Is the cost benefit tradeoff favourable?
- Is it hard or easy to implement?
- Does it take a long time?
- Does it require knowledge?
- Does it require resources?
- What will be the benefit to users?
- Is it likely there will be new users because of this feature?
- Will this feature require maintenance?
- …
F) Is this a nice issue for students or newcomers to JabRef (e.g. good first issue, fulfills certain requirements relevant to software engineering courses)?
- yes
- no
G) While I try to be as objective as possible, I am not free from subjectivity. - Do I think this is an important issue based on my gut feeling and personal preferences?
- yes
- no
H) Does this issue prevent compilation or installation of JabRef?
- yes
- no
I) Does this issue pose serious performance degradation?
- yes
- no
I am sure, I have forgotten the one or the other principle.
While I acknowledge, every issue is important, I think, there are some that are more important than others.
You will notice that there is the “maintainers focus” projects page. That one is often more of a backlog for issues they/we do not want to forget about, because they are important or interesting, but it does not automatically mean, that somebody is currently working on it. Also, the issues that are in the “for future” projects page are often exceedingly difficult to implement, so unfortunately, it is very rare for them to get implemented. In reality, what you see is that many issues from all over the projects pages will receive attention and low, medium and highly important issues will be implemented. You will see that many issues are fixed by maintainers and by students and some external contributors that have very specific needs or motivations. Not every issue is suitable for students, so there is a natural limitation about what gets fixed. And naturally, maintainers have their own preferences of what they like to see in JabRef too. Maintainers, not exclusively, but also spend a lot of time fixing issues that are just about keeping up with maintenance. Updating lucene search index from older to newer versions for instance.They fix a lot of regressions. Something breaks, so they try to fix it. The most notable issue that was fixed with JabRef 5.10, was something that is not immediately felt by users: The “method too large” exception. JabRef had hit JavaFX’s method limit and this caused many issues during development, as no new methods could be added to JabRef’s code base. So it was increasingly difficult to implement new features, but this is something that is difficult to explain to users. Sometimes these code relevant issues are in private issue trackers by maintainers or not tracked at all, because they are simply “known” by maintainers. For example, GitHub actions are often automatically triggered and notify maintainers, once fetchers fail to fetch.
Last but not least, I want to make you aware that, while we try, there will always be more issues than issues fixed. There are many variables. For example, time constraints (by developers), resource constraints or technical or architectural limitations in the code.
I hope this was of help to you and everybody else.
1 Like
Maybe the most accurate short term description of JabRef’s roadmap are its “pull-requests”
Fixing issues sometimes is like Hal trying to fix a light-bulb - (from Malcolm in the Middle S03E06 - Health Scare).
In general, JabRef tries to make a release each three months. Mostly, there are 6 months passing until a release happens. What we are assigning are things, that we are definitively including. These are listed at the repsective milestone at Milestones - JabRef/jabref · GitHub.
We try to organize issues into boards (Projects · jabref · GitHub) - and discuss them in bi-weekly DevCalls.
Many improvements come from students (via the board Candidates for University Projects · GitHub) - and we need a large amount of time to make them ready for JabRef. Thus, there is little time for “big things”, but we try hard to get things included.
@thedino-girl To get features in, we also need users to test. May I ask you to try the bulid at https://builds.jabref.org/pr-10496/ - whether it fixed the issue preferences: external file types duplicates · Issue #10271 · JabRef/jabref · GitHub