Fedora developer portal - proof of concept

[Adam Samalik]

> 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 at redhat.com>
To: "Adam Samalik" <asamalik at redhat.com>, "Development discussions related to Fedora" <devel at lists.fedoraproject.org>
Cc: "Fedora Environment and Stacks Working Group mailing list" <env-and-stacks at lists.fedoraproject.org>, duffy at redhat.com
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