[ 
https://issues.apache.org/jira/browse/SOLR-16455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeb Nix updated SOLR-16455:
---------------------------
    Description: 
Link to the mailing list disscussion thread: 
[https://lists.apache.org/thread/kdzl9v7byhj6dnkzwbvtyfb5dok33dbs] 

GitHub is where people are at when they lookup for Solr (or basically any 
project). Most of the modern projects that have been started with Jira and 
mailing lists have migrated to Github in the last few years. Lucene did that 
just now for the Issues which has allowed me to explore much more of their 
issues. GitHub works great and many think that it works even better.

In my opinion, when the issues are managed on Github, it is much simpler to 
collaborate and they will get wider exposure since developers are spending time 
on Github anyway (whether if it's for their projects or for looking at the 
actual source code). It is also important to mention that it is pretty 
cumbersome for a new contributor that wants to add stuff to Solr, to talk about 
this via mail, then translate them to Jira of the issues, and just after that 
submit a PR on Github. e.g. 3 different systems for each process.

Other advantages are in the area of integrating code with issues. Take a look 
at a new issue that has been submitted to Lucene, in which one can point to a 
specific line / introduce sophisticated code blocks:

!image-2022-10-11-02-25-04-799.png|width=886,height=288!

!image-2022-10-11-02-38-52-609.png|width=859,height=703!

These are just simple examples, but I can easily dive into all of the minor and 
major advantages of writing issues on Github rather than in different places. 
I'll only mention now that the ability to write MD files is much more 
convenient to a user that writing MD on PRs, and using two different text 
editors for mail and Jira.

The main advantages of migration are:
 * Easier to evolve the community and expose Solr Issues to newbies
 * Ability to integrate code with issues
 * Using a unified format for writing text - Markdowns
 * A more modern and comfortable UI
 * A unified UI for everything regarding Solr
 * Issues templates
 * Wider and more understandable usage of votes and feelings (with emojis)
 * All Solr contributors and most Solr users have a GitHub account. Not all of 
them have a Jira ASF account.
 * All Solr contributors and most Solr users are spending time on GitHub anyway.

Actually, I thought such a great move (for me at least) would never happen in 
Solr in the next years since I didn't think that the community sees & 
understands the many advantages yet. But now that the Lucene guys did this, I 
believe that it is possible for Solr too. As a reference, here's the relevant 
LUCENE-10557 that suggested the migration. Note that this issue suggests a 
wider migration - not only for GitHub Issues (and later Github Projects to 
manage them) but also for Solr Operator is of course a great live example of 
this. Currently, Solr Operator manages releases with milestones and labels 
issues/ PRs.

Referencing the tool used by Lucene for performing the task 
[https://github.com/apache/lucene-jira-archive]. This would be great for the 
migration of issues. The major tasks would be:
 * Get a consensus about the migration among committers
 * Choose issues that should be moved to GitHub - We'll migrate all issues 
towards an atomic switch to GitHub if no major technical obstacles show up.

 * 
 ** Write a migration script
 * Prepare a complete migration tool
 ** See [https://github.com/apache/lucene-jira-archive/issues/5] as a reference 
for the Lucene's one
 * Build the convention for issue label/milestone management

 * 
 ** Do some experiments on a sandbox repository 
[https://github.com/jebnix/sandbox-SOLR-16455] 
 ** Make documentation for metadata (label/milestone) management 
 * Enable Github issue on the Solr's repository
 ** Raise an issue on INFRA
 ** Set a mail hook to 
[iss...@lucene.apache.org|mailto:iss...@lucene.apache.org] (many thanks to the 
general mail group name)
 * Set a schedule for migration
 ** Give some time to committers to play around with issues/labels/milestones 
before the actual migration
 ** Make an announcement on the mailing lists
 ** Show some text messages when opening a new Jira issue
h4.  

  was:
NOTE - this is a proposal, and the comments for this are intended to become a 
practicle discussion, in case there is a consensus. A mailing discussion would 
get opened as an addition.

GitHub is where people are at when they lookup for Solr (or basically any 
project). Most of the modern projects that have been started with Jira and 
mailing lists have migrated to Github in the last few years. Lucene did that 
just now for the Issues which has allowed me to explore much more of their 
issues. GitHub works great and many think that it works even better.

In my opinion, when the issues are managed on Github, it is much simpler to 
collaborate and they will get wider exposure since developers are spending time 
on Github anyway (whether if it's for their projects or for looking at the 
actual source code). It is also important to mention that it is pretty 
cumbersome for a new contributor that wants to add stuff to Solr, to talk about 
this via mail, then translate them to Jira of the issues, and just after that 
submit a PR on Github. e.g. 3 different systems for each process.

Other advantages are in the area of integrating code with issues. Take a look 
at a new issue that has been submitted to Lucene, in which one can point to a 
specific line / introduce sophisticated code blocks:

!image-2022-10-11-02-25-04-799.png|width=886,height=288!

!image-2022-10-11-02-38-52-609.png|width=859,height=703!

These are just simple examples, but I can easily dive into all of the minor and 
major advantages of writing issues on Github rather than in different places. 
I'll only mention now that the ability to write MD files is much more 
convenient to a user that writing MD on PRs, and using two different text 
editors for mail and Jira.

The main advantages of migration are:
 * Easier to evolve the community and expose Solr Issues to newbies
 * Ability to integrate code with issues
 * Using a unified format for writing text - Markdowns
 * A more modern and comfortable UI
 * A unified UI for everything regarding Solr
 * Issues templates
 * Wider and more understandable usage of votes and feelings (with emojis)
 * All Solr contributors and most Solr users have a GitHub account. Not all of 
them have a Jira ASF account.
 * All Solr contributors and most Solr users are spending time on GitHub anyway.

Actually, I thought such a great move (for me at least) would never happen in 
Solr in the next years since I didn't think that the community sees & 
understands the many advantages yet. But now that the Lucene guys did this, I 
believe that it is possible for Solr too. As a reference, here's the relevant 
LUCENE-10557 that suggested the migration. Note that this issue suggests a 
wider migration - not only for GitHub Issues (and later Github Projects to 
manage them) but also for Solr Operator is of course a great live example of 
this. Currently, Solr Operator manages releases with milestones and labels 
issues/ PRs.

Referencing the tool used by Lucene for performing the task 
[https://github.com/apache/lucene-jira-archive]. This would be great for the 
migration of issues. The major tasks would be:
 * Get a consensus about the migration among committers
 * Choose issues that should be moved to GitHub - We'll migrate all issues 
towards an atomic switch to GitHub if no major technical obstacles show up.

 * 
 ** Write a migration script
 * Prepare a complete migration tool
 ** See [https://github.com/apache/lucene-jira-archive/issues/5] as a reference 
for the Lucene's one
 * Build the convention for issue label/milestone management

 * 
 ** Do some experiments on a sandbox repository 
[https://github.com/jebnix/sandbox-SOLR-16455] 
 ** Make documentation for metadata (label/milestone) management 
 * Enable Github issue on the Solr's repository
 ** Raise an issue on INFRA
 ** Set a mail hook to 
[iss...@lucene.apache.org|mailto:iss...@lucene.apache.org] (many thanks to the 
general mail group name)
 * Set a schedule for migration
 ** Give some time to committers to play around with issues/labels/milestones 
before the actual migration
 ** Make an announcement on the mailing lists
 ** Show some text messages when opening a new Jira issue
h4.  


> Migrate Jira to Github Issues and Github Projects
> -------------------------------------------------
>
>                 Key: SOLR-16455
>                 URL: https://issues.apache.org/jira/browse/SOLR-16455
>             Project: Solr
>          Issue Type: Wish
>      Security Level: Public(Default Security Level. Issues are Public) 
>          Components: github
>            Reporter: Jeb Nix
>            Priority: Trivial
>         Attachments: image-2022-10-11-02-25-04-799.png, 
> image-2022-10-11-02-38-52-609.png
>
>
> Link to the mailing list disscussion thread: 
> [https://lists.apache.org/thread/kdzl9v7byhj6dnkzwbvtyfb5dok33dbs] 
> GitHub is where people are at when they lookup for Solr (or basically any 
> project). Most of the modern projects that have been started with Jira and 
> mailing lists have migrated to Github in the last few years. Lucene did that 
> just now for the Issues which has allowed me to explore much more of their 
> issues. GitHub works great and many think that it works even better.
> In my opinion, when the issues are managed on Github, it is much simpler to 
> collaborate and they will get wider exposure since developers are spending 
> time on Github anyway (whether if it's for their projects or for looking at 
> the actual source code). It is also important to mention that it is pretty 
> cumbersome for a new contributor that wants to add stuff to Solr, to talk 
> about this via mail, then translate them to Jira of the issues, and just 
> after that submit a PR on Github. e.g. 3 different systems for each process.
> Other advantages are in the area of integrating code with issues. Take a look 
> at a new issue that has been submitted to Lucene, in which one can point to a 
> specific line / introduce sophisticated code blocks:
> !image-2022-10-11-02-25-04-799.png|width=886,height=288!
> !image-2022-10-11-02-38-52-609.png|width=859,height=703!
> These are just simple examples, but I can easily dive into all of the minor 
> and major advantages of writing issues on Github rather than in different 
> places. I'll only mention now that the ability to write MD files is much more 
> convenient to a user that writing MD on PRs, and using two different text 
> editors for mail and Jira.
> The main advantages of migration are:
>  * Easier to evolve the community and expose Solr Issues to newbies
>  * Ability to integrate code with issues
>  * Using a unified format for writing text - Markdowns
>  * A more modern and comfortable UI
>  * A unified UI for everything regarding Solr
>  * Issues templates
>  * Wider and more understandable usage of votes and feelings (with emojis)
>  * All Solr contributors and most Solr users have a GitHub account. Not all 
> of them have a Jira ASF account.
>  * All Solr contributors and most Solr users are spending time on GitHub 
> anyway.
> Actually, I thought such a great move (for me at least) would never happen in 
> Solr in the next years since I didn't think that the community sees & 
> understands the many advantages yet. But now that the Lucene guys did this, I 
> believe that it is possible for Solr too. As a reference, here's the relevant 
> LUCENE-10557 that suggested the migration. Note that this issue suggests a 
> wider migration - not only for GitHub Issues (and later Github Projects to 
> manage them) but also for Solr Operator is of course a great live example of 
> this. Currently, Solr Operator manages releases with milestones and labels 
> issues/ PRs.
> Referencing the tool used by Lucene for performing the task 
> [https://github.com/apache/lucene-jira-archive]. This would be great for the 
> migration of issues. The major tasks would be:
>  * Get a consensus about the migration among committers
>  * Choose issues that should be moved to GitHub - We'll migrate all issues 
> towards an atomic switch to GitHub if no major technical obstacles show up.
>  * 
>  ** Write a migration script
>  * Prepare a complete migration tool
>  ** See [https://github.com/apache/lucene-jira-archive/issues/5] as a 
> reference for the Lucene's one
>  * Build the convention for issue label/milestone management
>  * 
>  ** Do some experiments on a sandbox repository 
> [https://github.com/jebnix/sandbox-SOLR-16455] 
>  ** Make documentation for metadata (label/milestone) management 
>  * Enable Github issue on the Solr's repository
>  ** Raise an issue on INFRA
>  ** Set a mail hook to 
> [iss...@lucene.apache.org|mailto:iss...@lucene.apache.org] (many thanks to 
> the general mail group name)
>  * Set a schedule for migration
>  ** Give some time to committers to play around with issues/labels/milestones 
> before the actual migration
>  ** Make an announcement on the mailing lists
>  ** Show some text messages when opening a new Jira issue
> h4.  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org

Reply via email to