Talk:2024-02-23 - Revision history

Tim: .

2024-02-27T20:51:35Z

← Older revision		Revision as of 16:51, 27 February 2024
Line 12:		Line 12:

	''— [[User:ChrisKCMO\|ChrisKCMO]] ([[User talk: ChrisKCMO\|talk]])'' 22:18, 23 February 2024 (EST)		''— [[User:ChrisKCMO\|ChrisKCMO]] ([[User talk: ChrisKCMO\|talk]])'' 22:18, 23 February 2024 (EST)
			:Well-said, Chris! ''— [[User:Tim\|Tim]] ([[User talk: Tim \|talk]])'' 15:51, 27 February 2024 (EST)

ChrisKCMO at 22:20, 25 February 2024

2024-02-25T22:20:08Z

← Older revision		Revision as of 18:20, 25 February 2024
Line 1:		Line 1:
	== Windows and Linux software development; relates to section "Henry update" ==		== Windows and Linux software development; relates to section "[[2024-02-23#Henry_update\|Henry update]]" ==

	Here's sharing some informal "thinking out loud" thoughts and hoping that adding these notes as a "Talk" page isn't a problem for how this Wiki is being organized. This is being written in response to there having been some discussion of Windows vs. Linux in today's meeting notes.		Here's sharing some informal "thinking out loud" thoughts and hoping that adding these notes as a "Talk" page isn't a problem for how this Wiki is being organized. This is being written in response to there having been some discussion of Windows vs. Linux in today's meeting notes.

ChrisKCMO: Adjusted to expand on programming languages utilized by different contributors.

2024-02-25T22:18:23Z

Adjusted to expand on programming languages utilized by different contributors.

← Older revision		Revision as of 18:18, 25 February 2024
Line 3:		Line 3:
	Here's sharing some informal "thinking out loud" thoughts and hoping that adding these notes as a "Talk" page isn't a problem for how this Wiki is being organized. This is being written in response to there having been some discussion of Windows vs. Linux in today's meeting notes.		Here's sharing some informal "thinking out loud" thoughts and hoping that adding these notes as a "Talk" page isn't a problem for how this Wiki is being organized. This is being written in response to there having been some discussion of Windows vs. Linux in today's meeting notes.

	Ideally there would be more consistency with the targeted platforms and selected languages, but the nature of volunteering is that people bring to the table what they have readily available to easily put into use, quickly and conveniently. I suspect that other open source volunteer projects run into these types of challenges. We each have particular leanings or preferences with coding~~, with~~ Henry ~~focused on~~ Java and JavaScript, Sergei using PHP and Python, Larry using Ruby (I think?), Shelly using Windows-friendly languages (~~I'm guessing~~ C# or VB), and additional contributors out there likely using other styles and preferences.		Ideally there would be more consistency with the targeted platforms and selected languages, but the nature of volunteering is that people bring to the table what they have readily available to easily put into use, quickly and conveniently. I suspect that other open source volunteer projects run into these types of challenges. We each have particular leanings or preferences with coding: Henry using Java and JavaScript; Sergei using PHP, JavaScript and Python; Larry using Ruby (I think?); Shelly using PHP and JavaScript and perhaps Windows-friendly languages (maybe C#/VB?); and additional contributors out there likely using other styles and preferences.

	While it would probably be counterproductive to suggest steering contributors towards a primary or preferred platform, and a standard development environment and language, maybe a compromise would be to explore some middle ground in this regard that contributors could agree to work towards -- some combination that might over time lead to increased usage of an agreed upon set of common and consistent tools, languages and standards in software development and with regards to product delivery.		While it would probably be counterproductive to suggest steering contributors towards a primary or preferred platform, and a standard development environment and language, maybe a compromise would be to explore some middle ground in this regard that contributors could agree to work towards -- some combination that might over time lead to increased usage of an agreed upon set of common and consistent tools, languages and standards in software development and with regards to product delivery.

ChrisKCMO at 03:18, 24 February 2024

2024-02-24T03:18:20Z

← Older revision		Revision as of 23:18, 23 February 2024
Line 11:		Line 11:
	Some of the challenges with our different approaches to code creation are partially mitigated by the different products leveraging agreed upon interfaces and syntax (APIs) to talk, even with them being independent and standalone products, and maybe this approach -- separation of concerns and data exchanges via services/APIs -- negates concerns about the challenges with our different approaches to writing code and product delivery. Yet it still seems that KSF might benefit by spending some time on collaborations among developers, which might lead to recognizing each other's different styles of creation and possibly even nudging contributors towards coming more into alignment with one another over time with respect to tools, languages and product delivery approaches. If the active software developers are able to find a time outside of business hours (i.e., evenings or weekends) to meet, maybe recurring extra meetings or special breakout sessions, then I'd like to try to attend those collaborations and see if I might be of any help.		Some of the challenges with our different approaches to code creation are partially mitigated by the different products leveraging agreed upon interfaces and syntax (APIs) to talk, even with them being independent and standalone products, and maybe this approach -- separation of concerns and data exchanges via services/APIs -- negates concerns about the challenges with our different approaches to writing code and product delivery. Yet it still seems that KSF might benefit by spending some time on collaborations among developers, which might lead to recognizing each other's different styles of creation and possibly even nudging contributors towards coming more into alignment with one another over time with respect to tools, languages and product delivery approaches. If the active software developers are able to find a time outside of business hours (i.e., evenings or weekends) to meet, maybe recurring extra meetings or special breakout sessions, then I'd like to try to attend those collaborations and see if I might be of any help.

	''— [[User:ChrisKCMO\|ChrisKCMO]] ([[User talk: ChrisKCMO\|talk]])'' ~~2211~~, 23 February 2024 (EST)		''— [[User:ChrisKCMO\|ChrisKCMO]] ([[User talk: ChrisKCMO\|talk]])'' 22:18, 23 February 2024 (EST)

ChrisKCMO at 03:11, 24 February 2024

2024-02-24T03:11:59Z

← Older revision		Revision as of 23:11, 23 February 2024
Line 11:		Line 11:
	Some of the challenges with our different approaches to code creation are partially mitigated by the different products leveraging agreed upon interfaces and syntax (APIs) to talk, even with them being independent and standalone products, and maybe this approach -- separation of concerns and data exchanges via services/APIs -- negates concerns about the challenges with our different approaches to writing code and product delivery. Yet it still seems that KSF might benefit by spending some time on collaborations among developers, which might lead to recognizing each other's different styles of creation and possibly even nudging contributors towards coming more into alignment with one another over time with respect to tools, languages and product delivery approaches. If the active software developers are able to find a time outside of business hours (i.e., evenings or weekends) to meet, maybe recurring extra meetings or special breakout sessions, then I'd like to try to attend those collaborations and see if I might be of any help.		Some of the challenges with our different approaches to code creation are partially mitigated by the different products leveraging agreed upon interfaces and syntax (APIs) to talk, even with them being independent and standalone products, and maybe this approach -- separation of concerns and data exchanges via services/APIs -- negates concerns about the challenges with our different approaches to writing code and product delivery. Yet it still seems that KSF might benefit by spending some time on collaborations among developers, which might lead to recognizing each other's different styles of creation and possibly even nudging contributors towards coming more into alignment with one another over time with respect to tools, languages and product delivery approaches. If the active software developers are able to find a time outside of business hours (i.e., evenings or weekends) to meet, maybe recurring extra meetings or special breakout sessions, then I'd like to try to attend those collaborations and see if I might be of any help.

	''— [[User:~~Chris~~\|~~Chris~~]] ([[User talk: ~~Chris~~\|talk]])'' ~~2209~~, 23 February 2024 (EST)		''— [[User:ChrisKCMO\|ChrisKCMO]] ([[User talk: ChrisKCMO\|talk]])'' 2211, 23 February 2024 (EST)

ChrisKCMO at 03:09, 24 February 2024

2024-02-24T03:09:43Z

← Older revision		Revision as of 23:09, 23 February 2024
Line 10:		Line 10:

	Some of the challenges with our different approaches to code creation are partially mitigated by the different products leveraging agreed upon interfaces and syntax (APIs) to talk, even with them being independent and standalone products, and maybe this approach -- separation of concerns and data exchanges via services/APIs -- negates concerns about the challenges with our different approaches to writing code and product delivery. Yet it still seems that KSF might benefit by spending some time on collaborations among developers, which might lead to recognizing each other's different styles of creation and possibly even nudging contributors towards coming more into alignment with one another over time with respect to tools, languages and product delivery approaches. If the active software developers are able to find a time outside of business hours (i.e., evenings or weekends) to meet, maybe recurring extra meetings or special breakout sessions, then I'd like to try to attend those collaborations and see if I might be of any help.		Some of the challenges with our different approaches to code creation are partially mitigated by the different products leveraging agreed upon interfaces and syntax (APIs) to talk, even with them being independent and standalone products, and maybe this approach -- separation of concerns and data exchanges via services/APIs -- negates concerns about the challenges with our different approaches to writing code and product delivery. Yet it still seems that KSF might benefit by spending some time on collaborations among developers, which might lead to recognizing each other's different styles of creation and possibly even nudging contributors towards coming more into alignment with one another over time with respect to tools, languages and product delivery approaches. If the active software developers are able to find a time outside of business hours (i.e., evenings or weekends) to meet, maybe recurring extra meetings or special breakout sessions, then I'd like to try to attend those collaborations and see if I might be of any help.

			''— [[User:Chris\|Chris]] ([[User talk: Chris\|talk]])'' 2209, 23 February 2024 (EST)

ChrisKCMO: /* Windows and Linux software development; relates to section "Henry update" */ new section

2024-02-24T02:49:36Z

Windows and Linux software development; relates to section "Henry update": new section

New page

== Windows and Linux software development; relates to section "Henry update" ==

Here's sharing some informal "thinking out loud" thoughts and hoping that adding these notes as a "Talk" page isn't a problem for how this Wiki is being organized. This is being written in response to there having been some discussion of Windows vs. Linux in today's meeting notes.

Ideally there would be more consistency with the targeted platforms and selected languages, but the nature of volunteering is that people bring to the table what they have readily available to easily put into use, quickly and conveniently. I suspect that other open source volunteer projects run into these types of challenges. We each have particular leanings or preferences with coding, with Henry focused on Java and JavaScript, Sergei using PHP and Python, Larry using Ruby (I think?), Shelly using Windows-friendly languages (I'm guessing C# or VB), and additional contributors out there likely using other styles and preferences.

While it would probably be counterproductive to suggest steering contributors towards a primary or preferred platform, and a standard development environment and language, maybe a compromise would be to explore some middle ground in this regard that contributors could agree to work towards -- some combination that might over time lead to increased usage of an agreed upon set of common and consistent tools, languages and standards in software development and with regards to product delivery.

I can relate to Shelly's observations regarding the obstacles of Windows vs. Linux in KSF; my primary focus during the day is using Visual Studio and C# .NET within the Microsoft Windows ecosystem. If all of the different components, libraries, products and services could be written in just one language, and leverage a single framework and platform, then contributors might be more likely to collaborate more closely and even work on each other's projects. Unfortunately this is unlikely to happen, as people tend to gravitate towards using a particular set tools with an almost religious fervor, and getting more people to volunteer more time is difficult. Something that we can likely agree on is where personal views and moral convictions are concerned as pertain to efforts to decrease dependencies on technologies which are likely to limit personal freedoms and communications. In this regard, open source and Linux tend to win out when compared with other technology ecosystems, which is why I lean into Linux, C and Python in my spare time. But proprietary technologies aren't going away and people will continue to be comfortable with (for instance) Windows and Mac environments, so delivering to these platforms is necessary.

Some of the challenges with our different approaches to code creation are partially mitigated by the different products leveraging agreed upon interfaces and syntax (APIs) to talk, even with them being independent and standalone products, and maybe this approach -- separation of concerns and data exchanges via services/APIs -- negates concerns about the challenges with our different approaches to writing code and product delivery. Yet it still seems that KSF might benefit by spending some time on collaborations among developers, which might lead to recognizing each other's different styles of creation and possibly even nudging contributors towards coming more into alignment with one another over time with respect to tools, languages and product delivery approaches. If the active software developers are able to find a time outside of business hours (i.e., evenings or weekends) to meet, maybe recurring extra meetings or special breakout sessions, then I'd like to try to attend those collaborations and see if I might be of any help.