> I think it probably makes sense to focus on http://devassistant.org/ and > https://dapi.devassistant.org/ as the entry points to the Fedora > developer experience... Agree. They can start with the interesting part - coding - first. > ...We may want to pick out particular assistants and > highlight them (especially if we design the Fedora DA package to come > with some assistants pre-installed), but I think it makes sense to push > the "comprehensive" side of the story further upstream... Exactly. We would provide information how to get it running on Fedora - like the current Ruby guide. (They can, of course, use DevAssistant) > ..., and have > developers.fedoraproject.org present a more filtered view, just as the > main Fedora repos represent a filtered view of the upstream software > repositories. > My rationale for that is that DA provides an abstraction layer over > various mundane technical details - if you're using a well-maintained DA > Assistant to automate setting up a particular kind of project, then your > own practices can automatically adapt as recommendations change... Good point. I didn't think about it this way. >...If > folks want to learn more about the details of a recommendation, they can > dig into the implementation of the relevant assistant, but if they don't > want to care, they don't have to. > The DA folks are also actively working on offering good support for the > "Container Tools" workflow coming out of Project Atomic - that's a > Vagrant+containers based approach designed to be cross-platform for > development purposes and cross-distro for both development and > deployment, so adopting it for web service development means folks are > automatically lowering the barriers to entry to contributing to and > deploying their project. That workflow also actively encourages folks to > clearly separate their unit testing from their behavioural testing. > Given a default assumption that folks are willing to use DevAssistant > (either through the GUI or through the CLI), then the following kinds of > questions could help guide site users to appropriate assistants: > * I want to build a web application, where do I start? > * I want to build a command line application, where do I start? > * I want to build a desktop GUI application, where do I start? > * I want to build a mobile application, where do I start? > * I want to work with the Raspberry Pi, where do I start? > * I want to work with Arduino devices, where do I start? > * I want to work with other embedded devices, where do I start? > * I want to provide online documentation for my project, where do I start? > * I want to collaborate effectively with others on my project, where do > I start? > That last one wouldn't be a pointer to any DA Assistants, but rather a > pointer to resources like choosealicence.com, and a review of some of > the available project hosting options (most notably GitLab, GitHub, > BitBucket and FedoraHosted) I really like the point about collaboration and choosing a license. It's essential and I totally missed it in the initial plan. > P.S. A note regarding the Raspberry Pi: I think this is a good example > of a case where cross-distro development support is important, as we'd > like to make it easy for folks to develop for the Raspberry Pi on Fedora > while targeting both the default Raspbian image and the Fedora Pi remix, > rather than only supporting developing for the latter. I like the hidden message in this note: "We don't want to vendor-lock you to Fedora. We want you to use it because it helps you, not because you have to." ----- Original Message ----- From: "Nick Coghlan" <ncoghlan@xxxxxxxxxx> To: "Adam Samalik" <asamalik@xxxxxxxxxx>, "Development discussions related to Fedora" <devel@xxxxxxxxxxxxxxxxxxxxxxx> Cc: "Fedora Environment and Stacks Working Group mailing list" <env-and-stacks@xxxxxxxxxxxxxxxxxxxxxxx>, duffy@xxxxxxxxxx Sent: Monday, 27 July, 2015 6:41:40 AM Subject: Re: Fedora developer portal - proof of concept On 07/24/2015 07:16 PM, Adam Samalik wrote: > Hi Nick, > > thanks! > > What I'm still missing in the current prototype is the "problem to be solved" starting point - as you pointed out at the env-and-stacks meeting. For example: I want to develop a web application. The site would give me options like Django, Flask, Ruby on Rails, PHP, Jekyll,... Or even better, something more precise like deciding the type of the web app: an application with backend and database, a static site, blog or a wiki page? The tech-specific overview would show up afterwards. Suitable tools and deployment option would show up as well. What do you think? I think it probably makes sense to focus on http://devassistant.org/ and https://dapi.devassistant.org/ as the entry points to the Fedora developer experience. We may want to pick out particular assistants and highlight them (especially if we design the Fedora DA package to come with some assistants pre-installed), but I think it makes sense to push the "comprehensive" side of the story further upstream, and have developers.fedoraproject.org present a more filtered view, just as the main Fedora repos represent a filtered view of the upstream software repositories. My rationale for that is that DA provides an abstraction layer over various mundane technical details - if you're using a well-maintained DA Assistant to automate setting up a particular kind of project, then your own practices can automatically adapt as recommendations change. If folks want to learn more about the details of a recommendation, they can dig into the implementation of the relevant assistant, but if they don't want to care, they don't have to. The DA folks are also actively working on offering good support for the "Container Tools" workflow coming out of Project Atomic - that's a Vagrant+containers based approach designed to be cross-platform for development purposes and cross-distro for both development and deployment, so adopting it for web service development means folks are automatically lowering the barriers to entry to contributing to and deploying their project. That workflow also actively encourages folks to clearly separate their unit testing from their behavioural testing. Given a default assumption that folks are willing to use DevAssistant (either through the GUI or through the CLI), then the following kinds of questions could help guide site users to appropriate assistants: * I want to build a web application, where do I start? * I want to build a command line application, where do I start? * I want to build a desktop GUI application, where do I start? * I want to build a mobile application, where do I start? * I want to work with the Raspberry Pi, where do I start? * I want to work with Arduino devices, where do I start? * I want to work with other embedded devices, where do I start? * I want to provide online documentation for my project, where do I start? * I want to collaborate effectively with others on my project, where do I start? That last one wouldn't be a pointer to any DA Assistants, but rather a pointer to resources like choosealicence.com, and a review of some of the available project hosting options (most notably GitLab, GitHub, BitBucket and FedoraHosted) Regards, Nick. P.S. A note regarding the Raspberry Pi: I think this is a good example of a case where cross-distro development support is important, as we'd like to make it easy for folks to develop for the Raspberry Pi on Fedora while targeting both the default Raspbian image and the Fedora Pi remix, rather than only supporting developing for the latter. -- Nick Coghlan Fedora Environments & Stacks Red Hat Developer Experience, Brisbane Software Development Workflow Designer & Process Architect -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
