About you
-
What Free Software projects did you contribute to? Please provide URLs that show what you have done by yourself. It does not need to be code: bug reports, meaningful discussions, mentoring, etc. are equally important.
- https://sourceforge.net/projects/xpn-db/
- https://bugs.jqueryui.com/ticket/6786
- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=702266
- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741265
- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=769155#17
- https://bugs.kde.org/show_bug.cgi?id=355555
- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=807902#25
- https://github.com/codemirror/codemirror5/issues/4228
- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883269
- https://rt.cpan.org/Public/Bug/Display.html?id=124972
- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=904441#67
- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905729
- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=963548#70
- https://github.com/Corion/WWW-Mechanize-Chrome/blob/master/Changes#L371
- https://github.com/twbs/bootstrap/issues/29235
- https://www.laciudadcomotexto.cl
- https://github.com/guardianproject/orbot/issues/680
- https://github.com/mdn/content/issues/9347
- https://github.com/go-gitea/gitea/pull/20458#pullrequestreview-1050115205
- https://github.com/go-gitea/gitea/issues/21742
- https://github.com/go-gitea/gitea/issues/21965
- https://github.com/go-gitea/gitea/pull/21966
-
What are your areas of expertise (use
[x])?- User Interface
- User eXperience
- Web design
- Infrastructure
- Sysadmin
- Development (whatever the programming language)
- Community management
- Funding
- Mentoring
- Project management
Your Free Software contributions
A successfull contribution
I created a bug report submitting patches attached to suggest corrections and the maintainer was very grateful and receptive.
- I had been crawling a lot of content using the perl library WWW-Mechanize-Chrome and had been stucked because after days of crawling all the RAM of the system was ate by the running script. I was suspicious about the library based in its immature development state.
- The case was a clear case of memory leak, so I incorporated a workaround consisting in restart the script each day in a way that the memory leak wasn't enough to exhaust the system memory, but each killing of the crawling process started to left a zombie process in the system, so I research the library code and found a fix.
- I went to the (former) issue tracker of the project (https://rt.cpan.org/Public/Dist/Display.html?Name=WWW-Mechanize-Chrome) and search issues related with mine, but I found nothing. There were a very few reports in the project tracker.
- I opened up an issue describing my necessity of restarting the script regularly, the issue itself and a patch file attached.
- Two days after the report, the maintainer replyed very grateful announcing the patch was applied and the fix will be available in the next release.
- 10 hours after the first report, I reported another issue addressing a memory leak, describing the bug and attaching a proof of concept script to ilustrate the problem.
- Next day I figured out that the problem became from a refactorization of code being done not much time ago, I developed a fix and provide a couple of patch files and a suggestion of implementation with respect to a method involved.
- The maintainer reply just at the same time of the previous one, very grateful for the diagnosis and for the patches.
- After a few hours, I figured out more points of failure, pointed out in the issue as a comment pointing to the source code, and ask if I should provide more patches.
- The maintainer reply patches wasn't needed, replying to my thanks with You're welcome! It's always great to have users for a module, and even
better if they provide solutions for the problems they find with my code, and incorporate my suggestions based in the understanding of my use case.
A difficult contribution
I created a bug report on gitea and got a fix in about 10 days.
- I was trying to contribute to solving a self-reported accessibility issue by developing some fixes and while testing them on a local instance with an accessibility validation tool, I detected a collision of HTML ID's which I realised reflected the existence of another bug affecting the comment citation functionality.
- I checked the gitea test instance but the bug conditions were almost impossible to reproduce.
- I checked the issue tracker to determine if the bug had already been reported. But I found nothing related.
- I submitted a new issue explaining the bug and providing some screenshots, without providing steps to reproduce it, but remarking that new instances easily address the problem in the first instance-wide issues reported.
- Minutes later, I provided a PR to fix the problem but my git skills are not very good, so I moved the fix with a patch file from the branch I was working on to a dedicated branch. Then I staged the patch file instead of the patched one because it was late and I was very tired, and then I did the commit in a hurry.
- The next day, a reviewer pointed out to me that the commit was wrong because I had a patched file instead of a modified file. I did a forced push to correct my mistake.
- In the following days nothing happened with the review so I did a sort of ping commenting 'thanks' and mentioning the first reviewer.
- I soon got a reply asking me if the correction might break the whole commenting functionality.
- I did further research with a slightly broader scope than the comment citing functionality to validate the correction of the entire comment functionality.
- With a better understanding of the problem, I made another commit and forced the push again.
- I commented the new fix by mentioning the new commit and thanking them for doing the review.
- Two days later, a new reviewer claimed that the fix would break all links to comments posted within past comments. The first reviewer confessed that he had never understood the bug and claimed that broken links would be unacceptable.
- At that point I realised that the reviewers did not understand the functionality I had found faulty, so I explained in the PR the specific scope of the reported bug and its consequences on user interaction.
- In those days I knew that in the first issues created in any instance of
giteaI could find the expressed issue with high probability, but I would need to know which repository had been created first and had been speculating ways to get its username/org and its own name to review its first issues. - I searched the API of the official Gitea test instance to find the first instance issue, but with no success; the internal ID of an issue or comment is never displayed via the API.
- Two days after the last interaction in the PR with the reviewers and I explaining the bug, I searched Codeberg's early issues from their Community repository and found the first issue of their instance with the bug expressed.
- I immediately commented on this presence of the bug as an example of existence in the reported issue, detailing its consequences and a way to reproduce it there.
- A few minutes later, the second reviewer approved the PR.
- Two days later I forced a push of a new commit refactoring the solution, leaving the javascript functions agnostic on the related IDs, changing the structure of them according to the one used in other functionalities of the templates, and adding 3 more templates affected by the bug and its solution, extending the use cases from quoting comments to 5 affected cases.
- Immediately a third reviewer suggested changes to provide a better way to construct the HTML ID's in the templates.
- I responded that the suggested structure for constructing the HTML IDs would start to be inconsistent with other IDs present on the next line of the file, and commented that the suggested change would not be very transparent between the issue case and the issuecomment case.
- The last reviewer accepted the response agreeing with me and approved the PR.
- A few minutes later, they reinforced the idea to the other reviewers that this HTML ID change would not break anything and merged the PR.
A failed contribution
I started developing an XML database with XQuery capabilities, starting with an open source XQuery parser and an XML compression research model. I started the project as a student and then started working full time, started a family and the project was abandoned and never got out of its alpha phase.
- The initial code had been developed by a professor who had been doing research for the university at a related research centre whose main topic was the Web.
- He had already published a library analysing the XQuery language as free software in some public repository.
- I got very good grades in a subject he taught, so he invited me to do XML-focused research with him.
- Then I started working with him, and while we were both working on a prototype XML database, the software was hosted within the university, with all the code GPL'd.
- In the meantime, I started researching compression as the main topic of my professional thesis focusing on XML, so I proposed to him to integrate my research into the database prototype. The query plan model is called Proximal Nodes.
- The research results obtained by the database were quite good but the implementation diverged too much focused on my research without enough support to be a functional database.
- When I finished my thesis, the professor left the university due to lack of support with his research.
- Before I left the university as a degreed professional I asked the head of the computer science department if I could freely publish the code, and he agreed, so the code was published on Source Forge as XPN as free software.
- Months later, I started working full time and became a father so time was very scarce and the professor didn't go any further either.
- Years later only one person asked if the XQuery parser was available because it was developed in C++ and he was interested in using it in another application.
I think the failure was to have developed a lot of very poorly documented code and never looked for ways to promote development and engagement.
Also, XML databases are not very popular engines and the XQuery language has only one robust implementation in the open source arena that leads both its development and the W3C's own XQuery standard, so it's a very difficult area to compete in.
<!--
[User Research](https://jdittrich.github.io/userNeedResearchBook/) is about observing how you use tools when creating Free Software. Ideally we would sit with you and take notes. This would give us clues about the challenges you are facing, how you overcome them. And also what you find useful, the patterns that help you be an efficient Free Software contributor.
This survey is a kind of shortcut that saves you and us valuable time. All you are expected to do is tell the story of what you did, as you remember it. Just the facts, in chronological order. There is no need to write down a story that is nice to read: bullet points are perfectly fine.
As much as you'd like to give your interpretation of why something was good or difficult, this is not in scope for this survey: it is all about collecting the facts that make your own personal experience unique. All the surveys will then be compiled and analyzed to get a idea of the [mental models](https://en.wikipedia.org/wiki/Mental_model) common to most Free Software contributors.
The Forgejo roadmap will use this output to figure out what matters most, what should be adressed first and why, based on factual evidence that you provided. It would be faster to rely on the decision of project leads. But, however brilliant they are, it will only reflect their own view of the world and not the diversity of Free Software contributors.
It takes time to build a user centric roadmap and there is no guarantee that what matters to you most will end up there. But it also is the best way for your voice to be heard and make a difference.
-->
# About you
- What Free Software projects did you contribute to? Please provide URLs that show what you have done by yourself. It does not need to be code: bug reports, meaningful discussions, mentoring, etc. are equally important.
1. https://sourceforge.net/projects/xpn-db/
1. https://bugs.jqueryui.com/ticket/6786
1. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=702266
1. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741265
1. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=769155#17
1. https://bugs.kde.org/show\_bug.cgi?id=355555
1. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=807902#25
1. https://github.com/codemirror/codemirror5/issues/4228
1. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883269
1. https://rt.cpan.org/Public/Bug/Display.html?id=124972
1. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=904441#67
1. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905729
1. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=963548#70
1. https://github.com/Corion/WWW-Mechanize-Chrome/blob/master/Changes#L371
1. https://github.com/twbs/bootstrap/issues/29235
1. https://www.laciudadcomotexto.cl
1. https://github.com/guardianproject/orbot/issues/680
1. https://github.com/mdn/content/issues/9347
1. https://github.com/go-gitea/gitea/pull/20458#pullrequestreview-1050115205
1. https://github.com/go-gitea/gitea/issues/21742
1. https://github.com/go-gitea/gitea/issues/21965
1. https://github.com/go-gitea/gitea/pull/21966
- What are your areas of expertise (use `[x]`)?
- [x] User Interface
- [x] User eXperience
- [x] Web design
- [x] Infrastructure
- [x] Sysadmin
- [x] Development (whatever the programming language)
- [ ] Community management
- [ ] Funding
- [ ] Mentoring
- [x] Project management
# Your Free Software contributions
<!--
Tell your story (actual experiences, not imaginary ones) however you feel more confortable.
Please remember that raw facts, in chronological order, are what we are trying to collect and what is most useful in the context of this survey. Here is an example of a useful story:
I created a bug report at https://codeberg.org/forgejo/forgejo and got a solution within a the hour.
* I visited https://codeberg.org/forgejo
* I noticed https://codeberg.org/forgejo/forgejo because it had a logo
* I clicked on the link and saw https://codeberg.org/forgejo/forgejo
* I clicked on "Issues" and saw https://codeberg.org/forgejo/forgejo/issues
* I typed "pipeline" in the **Search** input box and pressed enter
* The results show a few issues although none of them had pipeline in the title which led me to the conclusion that the search was also on the issue description
* None of the issue titles was a match for the problem I was facing
* I clicked on **New Issue**
* The first choice was **Bug Report** and I clicked on the **Get Started** button
* etc.
-->
## A successfull contribution
I created a bug report submitting patches attached to suggest corrections and the maintainer was very grateful and receptive.
* I had been crawling a lot of content using the perl library [WWW-Mechanize-Chrome](https://github.com/Corion/WWW-Mechanize-Chrome/) and had been stucked because after days of crawling all the RAM of the system was ate by the running script. I was suspicious about the library based in its immature development state.
* The case was a clear case of memory leak, so I incorporated a workaround consisting in restart the script each day in a way that the memory leak wasn't enough to exhaust the system memory, but each killing of the crawling process started to left a zombie process in the system, so I research the library code and found a fix.
* I went to the (former) issue tracker of the project (https://rt.cpan.org/Public/Dist/Display.html?Name=WWW-Mechanize-Chrome) and search issues related with mine, but I found nothing. There were a very few reports in the project tracker.
* I opened up an [issue](https://rt.cpan.org/Public/Bug/Display.html?id=129805) describing my necessity of restarting the script regularly, the issue itself and a patch file attached.
* Two days after the report, the maintainer replyed very grateful announcing the patch was applied and the fix will be available in the next release.
* 10 hours after the first report, I reported [another issue addressing a memory leak](https://rt.cpan.org/Public/Bug/Display.html?id=129808), describing the bug and attaching a proof of concept script to ilustrate the problem.
* Next day I figured out that the problem became from a refactorization of code being done not much time ago, I developed a fix and provide a couple of patch files and a suggestion of implementation with respect to a method involved.
* The maintainer reply just at the same time of the previous one, very grateful for the diagnosis and for the patches.
* After a few hours, I figured out more points of failure, pointed out in the issue as a comment pointing to the source code, and ask if I should provide more patches.
* The maintainer reply patches wasn't needed, replying to my thanks with *You're welcome! It's always great to have users for a module, and even
better if they provide solutions for the problems they find with my code*, and incorporate my suggestions based in the understanding of my use case.
## A difficult contribution
<!--
Try to remember how your last successfull contribution was done and retrace your steps. It is also fine to start a new contribution, now matter how small and take detailed notes as you go.
-->
I created a bug report on [gitea](https://github.com/go-gitea/gitea) and got a fix in about 10 days.
* I was trying to contribute to solving [a self-reported accessibility issue](https://github.com/go-gitea/gitea/issues/21742) by developing some fixes and while testing them on a local instance with an accessibility validation tool, I detected a collision of HTML ID's which I realised reflected the existence of another bug affecting the comment citation functionality.
* I checked [the gitea test instance](https://try.gitea.io) but the bug conditions were almost impossible to reproduce.
* I checked [the issue tracker](https://github.com/go-gitea/gitea/issues/) to determine if the bug had already been reported. But I found nothing related.
* I submitted a new issue [explaining the bug](https://github.com/go-gitea/gitea/issues/21965) and providing some screenshots, without providing steps to reproduce it, but remarking that new instances easily address the problem in the first instance-wide issues reported.
* Minutes later, I provided a [PR to fix the problem](https://github.com/go-gitea/gitea/pull/21966) but my git skills are not very good, so I moved the fix with a patch file from the branch I was working on to a dedicated branch. Then I staged the patch file instead of the patched one because it was late and I was very tired, and then I did the commit in a hurry.
* The next day, a reviewer pointed out to me that the commit was wrong because I had a patched file instead of a modified file. I did a forced push to correct my mistake.
* In the following days nothing happened with the review so I did a sort of ping commenting 'thanks' and mentioning the first reviewer.
* I soon got a reply asking me if the correction might break the whole commenting functionality.
* I did further research with a slightly broader scope than the comment citing functionality to validate the correction of the entire comment functionality.
* With a better understanding of the problem, I made another commit and forced the push again.
* I commented the new fix by mentioning the new commit and thanking them for doing the review.
* Two days later, a new reviewer claimed that the fix would break all links to comments posted within past comments. The first reviewer confessed that he had never understood the bug and claimed that broken links would be unacceptable.
* At that point I realised that the reviewers did not understand the functionality I had found faulty, so I explained in the PR the specific scope of the reported bug and its consequences on user interaction.
* In those days I knew that in the first issues created in any instance of `gitea` I could find the expressed issue with high probability, but I would need to know which repository had been created first and had been speculating ways to get its username/org and its own name to review its first issues.
* I searched the API of the official Gitea test instance to find the first instance issue, but with no success; the internal ID of an issue or comment is never displayed via the API.
* Two days after the last interaction in the PR with the reviewers and I explaining the bug, I searched Codeberg's early issues from their Community repository and found the first issue of their instance with the bug expressed.
* I immediately commented on this presence of the bug as an example of existence in the reported issue, detailing its consequences and a way to reproduce it there.
* A few minutes later, the second reviewer approved the PR.
* Two days later I forced a push of a new commit refactoring the solution, leaving the javascript functions agnostic on the related IDs, changing the structure of them according to the one used in other functionalities of the templates, and adding 3 more templates affected by the bug and its solution, extending the use cases from quoting comments to 5 affected cases.
* Immediately a third reviewer suggested changes to provide a better way to construct the HTML ID's in the templates.
* I responded that the suggested structure for constructing the HTML IDs would start to be inconsistent with other IDs present on the next line of the file, and commented that the suggested change would not be very transparent between the issue case and the issuecomment case.
* The last reviewer accepted the response agreeing with me and approved the PR.
* A few minutes later, they reinforced the idea to the other reviewers that this HTML ID change would not break anything and merged the PR.
<!--Your difficulties are the most a precious contribution to this survey. What got in the way? What did you do to overcome the problem? How long did it take you to figure out a workaround?-->
## A failed contribution
<!--Tell us why you had to give up. Was it because the process took too long? Because you were stuck and could not find a way to complete your contribution no matter how hard you tried?-->
I started developing an XML database with XQuery capabilities, starting with an open source XQuery parser and an XML compression research model. I started the project as a student and then started working full time, started a family and the project was abandoned and never got out of its alpha phase.
* The initial code had been developed by a professor who had been doing research for the university at a related research centre whose main topic was the Web.
* He had already published a library analysing the XQuery language as free software in some public repository.
* I got very good grades in a subject he taught, so he invited me to do XML-focused research with him.
* Then I started working with him, and while we were both working on a prototype XML database, the software was hosted within the university, with all the code GPL'd.
* In the meantime, I started researching compression as the main topic of my professional thesis focusing on XML, so I proposed to him to integrate my research into the database prototype. The query plan model is called Proximal Nodes.
* The research results obtained by the database were quite good but the implementation diverged too much focused on my research without enough support to be a functional database.
* When I finished my thesis, the professor left the university due to lack of support with his research.
* Before I left the university as a degreed professional I asked the head of the computer science department if I could freely publish the code, and he agreed, so the code was published on [Source Forge as XPN](https://sourceforge.net/projects/xpn-db/) as free software.
* Months later, I started working full time and became a father so time was very scarce and the professor didn't go any further either.
* Years later only one person asked if the XQuery parser was available because it was developed in C++ and he was interested in using it in another application.
I think the failure was to have developed a lot of very poorly documented code and never looked for ways to promote development and engagement.
Also, XML databases are not very popular engines and the XQuery language has only one robust implementation in the open source arena that leads both its development and the W3C's own XQuery standard, so it's a very difficult area to compete in.