There are too many interesting feature requests to consider all of them.
And I can work only on one feature at a time because I only use my free time which is very limited.
On the other side I work not for me, I work for you, freeplane users and community.
There are basically two ways how this situation could be improved.
1: If we could find a way to identify the top five feature requests, I would always work on one of them, and you could better influence it.
How could we do it?
2: I could try to start fundraizing for new feature development. Costs per a feature would be something between 300$ and say 3000$, probably mostly under 1000$ . Once the money for a feature is collected, I would implement it. If this works out it could allow me to spend much more time on Freeplane than I do now.
The nice thing about findraizing is that the donators pay only if the required amount of money could be raized.
May be we could try a combination of the first two options so that the community discusses for which options fundraizing is started, and I still do some of them for free as now, but I could work more if the donations are collected.
What do you think about it?
👍
1
Last edit: Dimitry Polivaev 2018-12-30
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
At this moment, I think that the main obstacle against community discussion is that SourceForge is not a great platform for the purpose. The UI is clumsy and ugly, and the feature set is miminal. GitHub projects generally have very lively discussions in the issues tracker.
I don't push the view that GitHub is vastly better than any alternative, but I think that a more modern and innovative platform would be helpful. Since GitHub appears to be currently hosting the code base, I would repeat my suggestion to migrate issues out of SF.
Templates for new issues and the automatic addition of links to bounty managers are a few features that are directly relevant to the questions already mentioned in this discussion.
I am sorry to speak unpleasantlly of SourceForge, which is hosting this discussion, but I feel that the points are relevant.
Also, GitLab is a common alternative to GitHub. I actually like it better. I find the interface more organized and intuitive than GitHub's, and interest in alternatives to GitHub has been sparked by the recent acquisition by Microsoft.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The current platform is not serving the community. SF lacks the features developers need to manage and prioritize, and also lacks the friendliness and flexibility users need to feel part of an engaging and vibrant community.
This discussion began eight months ago, and as far as I can find, it has yet to prompt any further activity.. Obviously, no one is impressed by such a slow rate of progress.
At this momemt, it seems clear that everyone is unhappy. We cannot expect any major improvement in quality of collaboration while maintaining the same channels of communication.
I respect the resistance to changing platforms, but it seems now is time to accept that the encumberances within the current platform are great enough that they must outweigh the costs of moving to a new one.
New solutions seem to become available constantly. Some platforms provide polls, which could help identify popular feature requests. Other platforms are simply discussion boards with modern and dynamic interfaces.. Some platforms provide all the needs of code management under one site. Each platform has limitations, and none is perfect. The same project can use several at once, for different activities. Any combination of the many available choices might facilitate the colloboration required to plan the future of the project.
If migration of issues is preventing progress, then just abandon all the issues and post an announcement asking individuals to submit their own issues again to a new system, if they want. If no one cares about an issue enough to submit it again, then let it be.
We cannot escape the need for change of one kind or another. I hope someone will make a decision soon.
Last edit: brainchild 2019-08-01
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Current policy: I decide which features I implement next based on following factors:
Has a feature been requested by a person who contributed to the freeplane development, documentation or helped the project by actively spreading information about freeplane,
How much I like the idea,
How many people request it,
Has the concrete use case for the requested feature been described so that I want to help because of feeling the empathy with the user,
How much effort should be spent.
There is also a special case if somebody wants to pay for development of concrete features.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
First, I would just delete the existing 10 years of requests, or at least all of the requests that were put in before the last stable release of Freeplane (or that are more than 2 years old, or whatever--just get rid of the backlog). No one is ever going to go through them all to look at them.
I suggest creating feature requests categories to help people more easily see if their request is a duplicate. Such as:
UI/navigation improvement
import/export
scripting
icons
totally new functions
integration with other programs
search/filter improvements
Force people to search current requests before making a new one (if possible), and make them put their requests into categories. If more people would vote on the feature requests using the tickets, then you could see more easily what's most wanted. And, if the feature request tickets were set up better, the discussion community could start to point people to that list and it would be used more.
I'm not sure how to do this, but if you can require moderator approval before feature request tickets are added, I'm willing to help moderate/approve requests. (help, not necessarily do it all myself)
Also, you could tag the requests with how difficult they are to implement in order to let users know what sorts of things are easy and hard. I have no idea what features are easy to do.
I don't know if you could use the feature request as a way to fundraise - probably you'd want another system where people could pledge money. I have a specific idea for a feature you might be able to fundraise for, but I'll put it in another thread.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The ticket tracker supplied by SourceForge is not the best, but also has many features not being fully utilized.
Of the nearly 1000 open feature requests, the overwhelming portion lack any upvotes. Normally, number of affected users is a substantial factor in determining the priority for resolving open tickets. Also, the overwhelming number of requests are not assigned. It appears that a very large number of requests have been submitted over the past years, and have been left largely neglected since they were first submitted. Any serious thinking on the topic of this thread should be principally directed tpward resolving this problem.
Generally, users should be free to submit requests, but no substitute exists for developers classifying and sorting submitted requests. To this end, developers are responsible for defining the guidelines for submitting requests, users are responsible for following the guidelines, and as such, developers have no obligation to commit resources toward interpretting requests that do not follow these guidelines.
My first suggestion is to make submission guidelines clear to anyone submitting requests. Many ticket systems allow administrators to have a sequence of text displayed along with the submission form. Many also allow the use of templates that the user is asked to modify, rather than to create a request from scratch. At least one of these features should be used if available. Minimally, users should be encouraged to upvote and comment on existing requests, rather than create new ones, in the case of duplication or sufficient overlap of ideas. If guidelines were plainly written, it would be very reasonable for developers to avoid comitting resources toward incomplete requests, freeing time to review and to sort requests with the appropriate formatting and information. Such a situation would help resolve the current problem of vast numbers of requests indefintely remaining inactive.
Additionally, I support the earlier suggestion of dropping outdated or inactive request. If the system supports a bulk operation to put a WONTFIX status on all requests that have seen no activity for two years, then I would support running this operation or a similar one.
Use cases play a role in clarifying the meaning and importance of a request, but are not necessarily the most important information, and can be confusing because the question of what constitutes a use case, and how much detail is required, depends substantially on the type of feature. Broadly, a well-reasoned argument about why a feature is widely useful, or fills an existing gap in functionality, is the most valuable component of a request, along with a clear description of the functionality desired. I do understand the concern that a use case can help motivate a developer to address an issue, because it provides a genuine, concrete storyline, in addition to an abstract argument given separately, much the same as humanitarian organizations often find more success encouraging donations through describing a single case over reporting large statistics.
Generally, factors that, in my view, would determine priority of requests, in addition to subjective factors, are:
1. Number of affected users.
2. Clarity and persuasiveness of the request, as submitted.
3. Whether the request represents functionality that the developer already considered, but has not done yet because of time or complexity constraints.
4. Whether the feature comports to the current functional paradigm, such as filling a glaring gap in existing functionality, compared to trying to expand the project in new directions. (For example, if someone notices that an application supports clipboard copy but not paste, then a paste feature would fill an obvious gap in the overall paradigm of clipboard interaction. In consttrast, a "smart clipboard" would be an expansion of the original idea that informed the current set of features.)
5. Difficulty to implement, including time investment, added design complexity, added code size, and extent of redesign of existing functionality. The latter factors are particularly important because they affect the project as a whole. If a feature would be hard to maintain, then the observation that initial implementation is easy cannot be considered in isolation. Overall project goals must be considered as well as the usefulness of the feature.
Reiterating my main suggestions:
1. Clarify instructions for submitting requests, and make instructions as visible as possible to users making a submission.
2. Take serious requests that are submitted properly, and discard the rest.
3. Delete or close long-inactive currently-pending requests.
Last edit: brainchild 2019-01-04
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Another suggestion, though maybe not what you were thinking: Noting that source is managed in Github, has anyone studied the feasability of migrating the issue set out of SourceForge? Github may support more features, and I assume that it would be advantageous if the system allows mapping a commit to the issue that prompted it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
For what it's worth, I am also in favour of a mass purge of old feature requests. The people who made them and had them ignored have either come to terms with their absence or stopped using the project by now. Either way, efforts should be concentrated on the needs and suggestions of current users.
(I was active in this community in about 2011, writing a bunch of scripts to help myself and other use Freeplane for writing. Then I moved on to other tools for note taking and brainstorming. Now I'm coming back, but I don't think anything I then thought is terribly relevant any longer)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I created search queries for "old tickets" and "new tickets". The split date is 2018-01-01 as ticket last modification date. There are 69 Tickets reported in query "new tickets". It still does not help me to identify the top 5.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think what the above comments are saying is that the current system is broken. There is no good way to identify the top 5 based on existing tickets. If we can improve the request system then the top 5 will become obvious.
At the very least, purge old requests, make it clear that you are now using the ticket system actively, and we can encourage people to vote more on the forums.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I do not see how deletion could help. And I do not need to understand it, if somebody takes responsibility for managing and transparently prioritizing feature requests.
Who could do it?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I guess I should've made my last comment here. I'm volunteering to begin the process / contribute to managing and prioritizing feature requests. I'm happy to take the lead if someone wants to authorize me, or to work with a currently authorized person.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@quickfold As a voluntary developer I want to easily find the top 5 mostly needed requests, understand why they are selected and know that the selection procedure is accepted by the community. If any of the top requests are too hard to be implemented I should be able to communicate it and ask for replacement. I do not need to care about the management beyond that myself.
If you want to make it happen just tell me which tools you need.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think I need to be listed as a possible "owner" for tickets. I'm not sure yet if I need other admin rights. Sourceforge tickets documentation is poor. Try that first and I'll let you know if it works.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
My impression is that one of the features developers like about GitHub is that it unifies the various concerns of managing the codebase and project by putting revision management, issue tracking, and documentation under a single home. Previously most projects relied on separate solutions for each of these concerns. In GitHub, issues, as they are resolved by commits and then merged upstream, are easily tracked through the integration with the source repository. GitHub still lacks a forum feature, though in many projects the issue tracker is a de facto forum with a designated tag for questions, which are not considered to relate to a modification request.
I hope you wouldn't find it distracting if I asked a question following from these considerations. If the entire set of desired issues could be imported from SourceForge to GitHub, and supposing for argument that it could be done with zero effort, would the development team then wish to use GitHub instead? In other words, is SourceForge being used for issues because of preference or legacy?
Last edit: brainchild 2019-01-13
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Freeplane is the answer to your question, both Github and Sourceforge are missing this functionality along with every forum. An alternative to switching to Github would be Sourceforge integration with Atom IDE.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It may be so, but the original question relates to feature requests, not community. Github (or GitLab) may work better for issue tracking, especially if Github is already hosting the code. If you want to build a community, then you might look separately for a platform that provides a forum or simiilar features. You can still, at the same time, use a developer-oriented tool for developer-ortiented tasks. I doubt you will find a single platform well-suited to handle both sets of concerns, and the comprehensive feature set of SourceForge does not imply that any of the specific features function well in any particular project.
Edit: It might be useful to consider whether you are you so impressed with SF for ether issue tracking or community discussion that you would not think it possible to find better solutions for each concern elsewhere. If it is possible to find solutions elsewhere, then you could further consider whether a single platform for all concerns is as valuable to you as what might be gained by using a better platfform for each concern.
Last edit: brainchild 2019-04-07
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
There are too many interesting feature requests to consider all of them.
And I can work only on one feature at a time because I only use my free time which is very limited.
On the other side I work not for me, I work for you, freeplane users and community.
There are basically two ways how this situation could be improved.
1: If we could find a way to identify the top five feature requests, I would always work on one of them, and you could better influence it.
How could we do it?
2: I could try to start fundraizing for new feature development. Costs per a feature would be something between 300$ and say 3000$, probably mostly under 1000$ . Once the money for a feature is collected, I would implement it. If this works out it could allow me to spend much more time on Freeplane than I do now.
The nice thing about findraizing is that the donators pay only if the required amount of money could be raized.
May be we could try a combination of the first two options so that the community discusses for which options fundraizing is started, and I still do some of them for free as now, but I could work more if the donations are collected.
What do you think about it?
Last edit: Dimitry Polivaev 2018-12-30
I think it's a good idea!
Last edit: Philippe Morin 2019-03-28
At this moment, I think that the main obstacle against community discussion is that SourceForge is not a great platform for the purpose. The UI is clumsy and ugly, and the feature set is miminal. GitHub projects generally have very lively discussions in the issues tracker.
I don't push the view that GitHub is vastly better than any alternative, but I think that a more modern and innovative platform would be helpful. Since GitHub appears to be currently hosting the code base, I would repeat my suggestion to migrate issues out of SF.
Templates for new issues and the automatic addition of links to bounty managers are a few features that are directly relevant to the questions already mentioned in this discussion.
I am sorry to speak unpleasantlly of SourceForge, which is hosting this discussion, but I feel that the points are relevant.
Also, GitLab is a common alternative to GitHub. I actually like it better. I find the interface more organized and intuitive than GitHub's, and interest in alternatives to GitHub has been sparked by the recent acquisition by Microsoft.
The current platform is not serving the community. SF lacks the features developers need to manage and prioritize, and also lacks the friendliness and flexibility users need to feel part of an engaging and vibrant community.
This discussion began eight months ago, and as far as I can find, it has yet to prompt any further activity.. Obviously, no one is impressed by such a slow rate of progress.
At this momemt, it seems clear that everyone is unhappy. We cannot expect any major improvement in quality of collaboration while maintaining the same channels of communication.
I respect the resistance to changing platforms, but it seems now is time to accept that the encumberances within the current platform are great enough that they must outweigh the costs of moving to a new one.
New solutions seem to become available constantly. Some platforms provide polls, which could help identify popular feature requests. Other platforms are simply discussion boards with modern and dynamic interfaces.. Some platforms provide all the needs of code management under one site. Each platform has limitations, and none is perfect. The same project can use several at once, for different activities. Any combination of the many available choices might facilitate the colloboration required to plan the future of the project.
If migration of issues is preventing progress, then just abandon all the issues and post an announcement asking individuals to submit their own issues again to a new system, if they want. If no one cares about an issue enough to submit it again, then let it be.
We cannot escape the need for change of one kind or another. I hope someone will make a decision soon.
Last edit: brainchild 2019-08-01
Current policy: I decide which features I implement next based on following factors:
Here's my suggestion, which I am willing to help implement: fix the existing feature request system, and improve it for going forward.
Currently there are way too many feature requests to even consider. There are also many duplicates, e.g. Higlight text search results, which is discussed here even though it has three open tickets:
https://sourceforge.net/p/freeplane/discussion/758437/thread/cabd49e8/
https://sourceforge.net/p/freeplane/featurerequests/758/
https://sourceforge.net/p/freeplane/featurerequests/2029/
https://sourceforge.net/p/freeplane/featurerequests/711/
First, I would just delete the existing 10 years of requests, or at least all of the requests that were put in before the last stable release of Freeplane (or that are more than 2 years old, or whatever--just get rid of the backlog). No one is ever going to go through them all to look at them.
I suggest creating feature requests categories to help people more easily see if their request is a duplicate. Such as:
UI/navigation improvement
import/export
scripting
icons
totally new functions
integration with other programs
search/filter improvements
Force people to search current requests before making a new one (if possible), and make them put their requests into categories. If more people would vote on the feature requests using the tickets, then you could see more easily what's most wanted. And, if the feature request tickets were set up better, the discussion community could start to point people to that list and it would be used more.
I'm not sure how to do this, but if you can require moderator approval before feature request tickets are added, I'm willing to help moderate/approve requests. (help, not necessarily do it all myself)
Also, you could tag the requests with how difficult they are to implement in order to let users know what sorts of things are easy and hard. I have no idea what features are easy to do.
I don't know if you could use the feature request as a way to fundraise - probably you'd want another system where people could pledge money. I have a specific idea for a feature you might be able to fundraise for, but I'll put it in another thread.
The ticket tracker supplied by SourceForge is not the best, but also has many features not being fully utilized.
Of the nearly 1000 open feature requests, the overwhelming portion lack any upvotes. Normally, number of affected users is a substantial factor in determining the priority for resolving open tickets. Also, the overwhelming number of requests are not assigned. It appears that a very large number of requests have been submitted over the past years, and have been left largely neglected since they were first submitted. Any serious thinking on the topic of this thread should be principally directed tpward resolving this problem.
Generally, users should be free to submit requests, but no substitute exists for developers classifying and sorting submitted requests. To this end, developers are responsible for defining the guidelines for submitting requests, users are responsible for following the guidelines, and as such, developers have no obligation to commit resources toward interpretting requests that do not follow these guidelines.
My first suggestion is to make submission guidelines clear to anyone submitting requests. Many ticket systems allow administrators to have a sequence of text displayed along with the submission form. Many also allow the use of templates that the user is asked to modify, rather than to create a request from scratch. At least one of these features should be used if available. Minimally, users should be encouraged to upvote and comment on existing requests, rather than create new ones, in the case of duplication or sufficient overlap of ideas. If guidelines were plainly written, it would be very reasonable for developers to avoid comitting resources toward incomplete requests, freeing time to review and to sort requests with the appropriate formatting and information. Such a situation would help resolve the current problem of vast numbers of requests indefintely remaining inactive.
Additionally, I support the earlier suggestion of dropping outdated or inactive request. If the system supports a bulk operation to put a WONTFIX status on all requests that have seen no activity for two years, then I would support running this operation or a similar one.
Use cases play a role in clarifying the meaning and importance of a request, but are not necessarily the most important information, and can be confusing because the question of what constitutes a use case, and how much detail is required, depends substantially on the type of feature. Broadly, a well-reasoned argument about why a feature is widely useful, or fills an existing gap in functionality, is the most valuable component of a request, along with a clear description of the functionality desired. I do understand the concern that a use case can help motivate a developer to address an issue, because it provides a genuine, concrete storyline, in addition to an abstract argument given separately, much the same as humanitarian organizations often find more success encouraging donations through describing a single case over reporting large statistics.
Generally, factors that, in my view, would determine priority of requests, in addition to subjective factors, are:
1. Number of affected users.
2. Clarity and persuasiveness of the request, as submitted.
3. Whether the request represents functionality that the developer already considered, but has not done yet because of time or complexity constraints.
4. Whether the feature comports to the current functional paradigm, such as filling a glaring gap in existing functionality, compared to trying to expand the project in new directions. (For example, if someone notices that an application supports clipboard copy but not paste, then a paste feature would fill an obvious gap in the overall paradigm of clipboard interaction. In consttrast, a "smart clipboard" would be an expansion of the original idea that informed the current set of features.)
5. Difficulty to implement, including time investment, added design complexity, added code size, and extent of redesign of existing functionality. The latter factors are particularly important because they affect the project as a whole. If a feature would be hard to maintain, then the observation that initial implementation is easy cannot be considered in isolation. Overall project goals must be considered as well as the usefulness of the feature.
Reiterating my main suggestions:
1. Clarify instructions for submitting requests, and make instructions as visible as possible to users making a submission.
2. Take serious requests that are submitted properly, and discard the rest.
3. Delete or close long-inactive currently-pending requests.
Last edit: brainchild 2019-01-04
Another suggestion, though maybe not what you were thinking: Noting that source is managed in Github, has anyone studied the feasability of migrating the issue set out of SourceForge? Github may support more features, and I assume that it would be advantageous if the system allows mapping a commit to the issue that prompted it.
For what it's worth, I am also in favour of a mass purge of old feature requests. The people who made them and had them ignored have either come to terms with their absence or stopped using the project by now. Either way, efforts should be concentrated on the needs and suggestions of current users.
(I was active in this community in about 2011, writing a bunch of scripts to help myself and other use Freeplane for writing. Then I moved on to other tools for note taking and brainstorming. Now I'm coming back, but I don't think anything I then thought is terribly relevant any longer)
I created search queries for "old tickets" and "new tickets". The split date is 2018-01-01 as ticket last modification date. There are 69 Tickets reported in query "new tickets". It still does not help me to identify the top 5.
I think what the above comments are saying is that the current system is broken. There is no good way to identify the top 5 based on existing tickets. If we can improve the request system then the top 5 will become obvious.
At the very least, purge old requests, make it clear that you are now using the ticket system actively, and we can encourage people to vote more on the forums.
Unfortunately, there is no easy way to purge older requests on Source Forge.
The new query allows to see only new requests and ignore older ones.
Bulk move is possible. You could move the older requests to an archive.
It looks like you can bulk delete tickets 250 at a time. I didn't test it but if I'm authorized I'll delete some/all as you want.
I do not see how deletion could help. And I do not need to understand it, if somebody takes responsibility for managing and transparently prioritizing feature requests.
Who could do it?
I guess I should've made my last comment here. I'm volunteering to begin the process / contribute to managing and prioritizing feature requests. I'm happy to take the lead if someone wants to authorize me, or to work with a currently authorized person.
@quickfold As a voluntary developer I want to easily find the top 5 mostly needed requests, understand why they are selected and know that the selection procedure is accepted by the community. If any of the top requests are too hard to be implemented I should be able to communicate it and ask for replacement. I do not need to care about the management beyond that myself.
If you want to make it happen just tell me which tools you need.
I think I need to be listed as a possible "owner" for tickets. I'm not sure yet if I need other admin rights. Sourceforge tickets documentation is poor. Try that first and I'll let you know if it works.
I have given you some access rigths. Please check if it helps.
To see and run the queries visit https://sourceforge.net/p/freeplane/featurerequests
My impression is that one of the features developers like about GitHub is that it unifies the various concerns of managing the codebase and project by putting revision management, issue tracking, and documentation under a single home. Previously most projects relied on separate solutions for each of these concerns. In GitHub, issues, as they are resolved by commits and then merged upstream, are easily tracked through the integration with the source repository. GitHub still lacks a forum feature, though in many projects the issue tracker is a de facto forum with a designated tag for questions, which are not considered to relate to a modification request.
I hope you wouldn't find it distracting if I asked a question following from these considerations. If the entire set of desired issues could be imported from SourceForge to GitHub, and supposing for argument that it could be done with zero effort, would the development team then wish to use GitHub instead? In other words, is SourceForge being used for issues because of preference or legacy?
Last edit: brainchild 2019-01-13
I think github is even less a community building plattform than source forge. So I do not see how abandoning source forge as a platform could help.
Freeplane is the answer to your question, both Github and Sourceforge are missing this functionality along with every forum. An alternative to switching to Github would be Sourceforge integration with Atom IDE.
It may be so, but the original question relates to feature requests, not community. Github (or GitLab) may work better for issue tracking, especially if Github is already hosting the code. If you want to build a community, then you might look separately for a platform that provides a forum or simiilar features. You can still, at the same time, use a developer-oriented tool for developer-ortiented tasks. I doubt you will find a single platform well-suited to handle both sets of concerns, and the comprehensive feature set of SourceForge does not imply that any of the specific features function well in any particular project.
Edit: It might be useful to consider whether you are you so impressed with SF for ether issue tracking or community discussion that you would not think it possible to find better solutions for each concern elsewhere. If it is possible to find solutions elsewhere, then you could further consider whether a single platform for all concerns is as valuable to you as what might be gained by using a better platfform for each concern.
Last edit: brainchild 2019-04-07